Subject: [TLS] AD review of draft-ietf-tls-falsestart-01

From: Stephen Farrell <[email-masked]>
Date: Wed, 23 Mar 2016 15:14:47 +0000

Hiya,

I've done my AD review of this and have three questions
I'd like to ask before starting IETF last call. I mostly
care about the answer to #3. #1 is just a suggestion that
might avoid some process-crap and #2 is just me being
curious (unless #2 turns out to be a part of #3).

(1) Why experimental? Wouldn't this be better as info
and documented as "here's a spec for a thing that's
widely deployed." I fear we may get questions like
"what's the experiment?", "where's this going in
future?" if this aims for experimental, and info may
avoid that esp if we really want people to move to
TLS1.3. I also didn't see list discussion about what
kind of RFC to aim for, but maybe it was discussed at
a meeting or interim? (Apologies if I missed that in
my scan of the list.)

(2) The write up and some mail list traffic and AGL's
bloggy thing all refer to NPN, but there's no mention of
NPN or ALPN in the draft.  What's up with that? (Not
saying that needs to be explained, but I wondered.)

(3) Why is there no description of the reasons for all
the MUST only use whitelisted <foo> and for the choices
that are whitelisted?  Wouldn't omitting that tend to
lead people to use this more badly?  That could be done
with some explanatory text and using some of the
references below maybe. Or, if we don't really want new
folks to implement this (do we?) then just saying that
might mean it's ok to not explain the "why." (And then
you could also address #1 above then by issuing this
as an historic RFC too if you wanted.)

Cheers,
S.

Possible refs:
 - http://www.ieee-security.org/TC/SP2015/papers-archived/6949a535.pdf
   (esp Section V-C)
 - http://homes.esat.kuleuven.be/~fvercaut/papers/ACM2012.pdf
 - https://hal.inria.fr/hal-01184171/document
 - https://arxiv.org/pdf/1602.02396.pdf
 - https://eprint.iacr.org/2016/072.pdf

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 24 Mar 2016 01:38:18 +0100

> a meeting or interim? (Apologies if I missed that in

I'm myself torn between "Experimental" and "Informational" (certainly not
"Historic" because the spec has not been superseded by a more recent one
and is not obsolete for any other reason [
https://tools.ietf.org/html/rfc2026#section-4.2.4], unless we somehow
manage to complete TLS 1.3 standardization before this). Taking into
account how False Start is actually deployed (and taking into account that
we expect it to eventually be replaced by a TLS 1.3 mechanism) and how our
I-D is cited in research papers on TLS, "Experimental" sounds right to me:
the spec really is part of a research and development effort [
https://tools.ietf.org/html/rfc2026#section-4.2.4]. "Informational"
wouldn't be wrong either.

> saying that needs to be explained, but I wondered.)

The NPN dependency was a design decision for one implementation, but it's
not common to clients using False Start. For interoperability, you always
have to consider how to deal with what you expect to be deployed
*currently* (and NPN support certainly is one good indicator for False
Start tolerance, if you don't mind tons of false negatives), but I wouldn't
see much value in compiling the minutae of that in this kind of document:
it'll go stale quickly.

> lead people to use this more badly?

Well, I tried to capture the general reasoning in the spec -- but not the
detailed reasons for the specific choices suggested, because that again
would just go stale quickly.

In particular, I think this is an important observation in the I-D:

"If heuristically a small list of cipher suites and a single protocol
version is found to be sufficient for the majority of TLS handshakes in
practice, it could make sense to forego False Start for any handshake that
does not match this expected pattern, even if there is no concrete reason
to assume a cryptographic weakness."

So the whitelists should have algorithms that are actually used in practice
and that don't have critical weaknesses, but why exactly those particular
algorithms happen to get used in practice is mostly out of scope here.

Bodo

> That could be done

---

From: Martin Thomson <[email-masked]>
Date: Thu, 24 Mar 2016 16:27:20 +1100

On 24 March 2016 at 11:38, Bodo Moeller <[email-masked]> wrote:
> have to consider how to deal with what you expect to be deployed *currently*
> (and NPN support certainly is one good indicator for False Start tolerance,
> if you don't mind tons of false negatives), but I wouldn't see much value in
> compiling the minutae of that in this kind of document: it'll go stale
> quickly.

But I agree with this analysis, the original reason for the test was -
if a little iffy - rational. Correlation might not imply causation,
but sometimes correlation is all you need.

BTW, Firefox still has the option to require that a site advertise NPN
(or ALPN) before false starting.  It's off by default and hard to
find, but it's there.  And there are still people who flip that bit.

As a feature, it's not one we need to keep.  I certainly wouldn't want
to bless it by putting it in an RFC, Experimental or otherwise.  Let's
chalk that up to the ugly things we have to do to get things to work.

Which reminds me...

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Mar 2016 09:56:28 +0000

Hiya,

Thanks for the speedy response...

Again #3 below is what I care about, the other stuff isn't
a big deal.

On 24/03/16 00:38, Bodo Moeller wrote:
> account how False Start is actually deployed (and taking into

Right. TLS1.3 will hopefully make this historic, so we could just
park this in the RFC editor queue and have both RFCs emerge on the
same day with this one as Historic. With did that with DKIM (4871)
and DomainKeys (4870, Historic) for example. Note that I'm not arguing
for doing that, just raising the option if that's what the WG want
and if the list hasn't discussed it. I assume though that the WG
don't want to take this route so no need to discuss it more in that
case.

> account that

I think the latter matches much better myself, as there really is
no experiment being done here and we're not gonna develop this any
more once TLS1.3 is done, but whatever - I'm ok with saying that
the WG just wanted experimental. But you'll likely get asked this
again and again. At least we can now point at this thread and say
that it was discussed on the list though. (Which was partly why I
asked:-)

It'd be no harm though if a couple of others chimed in on this
just to there's recorded opinion from more than just the AD and
an author.

We can change to informational at the end of LC if need be, i.e.,
there's no need to hold stuff up for that and such a change then
doesn't add any delay.

> see much value in compiling the minutae of that in this kind of document:

Fair enough, thanks. (Same to Martin for his follow up.)

> would just go stale quickly.

Where are those general reasons stated? I don't see 'em.

> to assume a cryptographic weakness."

That may be important but it doesn't address the issue about which
I'm asking.

> algorithms happen to get used in practice is mostly out of scope here.

Why is the logic behind such security relevant choices out of scope?
That makes no sense to me. Let's imagine a new ciphersuite is invented
and folks start to wonder whether or not it's ok to whitelist that for
false-start - wouldn't they expect this document to explain (maybe
mostly via references) why some ciphersuites are not good enough to
whitelist? I would expect that to be clear.

And to be clear, I'm not asking for an essay, but more like some text
in the intro saying "False start is not safe for a ciphersuite that
has properties <A,B,C> such as <example> because of <problem>. See
[refs] for full details."

For added clarity it'd also be good to have something like:
"Ciphersuites MUST have <good-properties X,Y,Z> to be safe to
whitelist for false-start."

If figuring out text for the above is very hard, then I do think that
would indicate a real issue with this spec. If figuring that out is
just a minor bit of tedium, then I think it's worthwhile so that
future readers of the RFC can understand what's going on here, which
I don't think is the case from the current text.

Cheers,
S.

---

From: Sean Turner <[email-masked]>
Date: Thu, 31 Mar 2016 21:19:37 -0400

> there's no need to hold stuff up for that and such a change then

This draft started out as Informational and then we switched it Experimental.  The WG has not considered whether we should publish this should go Historic now, be held and publish as Historic later, etc.

How do folks feel about Historic vs Experimental vs Informational?

If we’re going to move it to Historic, then we’ve got a couple of options:

0) As described above: Get it approved by the IESG, hold it in RFC editor’s queue, and publish it as historic at the same time TLS 1.3 is published.

1) Approve it, get it published, and then make it Historic with another draft.

2) Approve it, get it published, and then make it Historic with an IESG initiated Protocol Action, which is a message that the IESG initiates requesting the status be changed similar to an IETF but requires no draft.

(there’s probably some other options like an adding an IESG note/new section that says “this goes to historic when TLS 1.3 is published, but I think the above three options seem more realistic.)

Option 0 is probably the least amount of work.  We just hold it, but in some sense I kind of tend to think that we’re punishing the authors.  There’s nothing they’ve really got to do, but it feels somehow like we’re hitting them upside the head with the process two-by-four.

Option 1 would be a total PITA.  People say that we can get a draft published quickly if we (the royal we) really want to, but my experience is otherwise.

Option 2 is something that I don't think we had in our toolkit when DKIM was being worked on.  The draft gets published the authors can move on and we (the process moths) can make sure the draft gets moved to Historic.  

What do the WG members think about the options of moving to historic?  Personally, I’d advocate option 2 because it keeps the work load on the chairs/AD :)

~snipped 2~

> Where are those general reasons stated? I don't see ‘em.

The whitelisted options are described in the bullets in s4 and those point to s5.*

It’s stuff like don’t use suspect symmetric ciphers.

> I don't think is the case from the current text.

I think this text is already present:

 Clients MUST NOT use the False Start protocol modification in a
 handshake unless the cipher suite uses a symmetric cipher that is
 considered cryptographically strong.

In the key exchange algorithms and client certificate type security considerations, there’s:

 The recommended whitelists are such that if cryptographic algorithms
 suitable for forward secrecy would possibly be negotiated, no False
 Start will take place if the current handshake fails to provide
 forward secrecy.

 .. and ..

 Forward secrecy can be achieved using ephemeral
 Diffie-Hellman or ephemeral Elliptic-Curve Diffie-Hellman ...

If we summarize these in the Introduction we’re good?

spt

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Dave Garrett <[email-masked]>
Date: Fri, 1 Apr 2016 01:07:51 -0400

> (there’s probably some other options like an adding an IESG note/new section that says “this goes to historic when TLS 1.3 is published, but I think the above three options seem more realistic.)

What looks simplest to me, would be to publish initially as experimental, then have the TLS 1.3 specification obsolete it and contain language that explicitly changes its status to historic without additional action. Consensus to change status would be considered a part of the required consensus to publish TLS 1.3 as an RFC. The current TLS 1.3 draft already handwaves an informational RFC to standards track (RFC5289: ECC AES GCM), so adding another handwave to change another RFC's status like this seems to make the most sense.

Dave