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

From: Stephen Farrell <[email-masked]>
Date: Fri, 1 Apr 2016 13:19:29 +0100

Hi Sean,

Thanks for moving this along,

On 01/04/16 02:19, Sean Turner wrote:
> On Mar 24, 2016, at 05:56, Stephen Farrell
> <[email-masked]> wrote:
>> 
>> 
>> 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:
>>> "Stephen Farrell" <[email-masked]>:
>>> 
>>>> (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.)
>>> 
>>> 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
>> 
>> 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 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.
>> 
>> 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.
> 
> 
> 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 :)

I'm fine with any of the above.

> 
> ~snipped 2~
> 
>>> 
>>>> (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?
>>> 
>>> 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.
>> 
>> 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.*

I'm still not seeing it. I do see things listed, but I don't
see any reasons why the things are listed.

The closest I see we get for now is: "The TLS protocol already
relies on such a security property for authentication -- with
False Start, the same is needed for encryption." But there's
quite a gap between that statement and the set of rules given
here.

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

But surely that's tautological? When would we ever recommend
using dodgy stuff? I think what's missing is a description of
or reference to what is particularly going to go wrong if you
use a ciphersuite with known attacks and do false-start.

That'd give the reader a chance to do an informed evaluation
for themselves as to whether or not some ciphersuite is or is
not safe with false-start. (And that evaluation will be done
at various points in future.)

> 
>>> 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."
>> 
>> That may be important but it doesn't address the issue about which 
>> I'm asking.
>> 
>>> 
>>> 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.
>> 
>> 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.
> 
> 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?

No, I'm on about missing text not placement of text. Again if
we added something like "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" then we'd be done because a reader
could use that to analyse whether or not it is ok to use a future
ciphersuite (or a current one, being re-evaluated in the future) with
false-start.

Cheers,
S.

PS: If I'm just not managing to explain myself well here, we can
chat about it in B-A.

> 
> spt
> 
>> Cheers, S.
>> 
>> 
>>> 
>>> Bodo
>>> 
>>>> 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.)
>>> 
>> 
>> _______________________________________________ TLS mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/tls
> 
>

---

From: Sean Turner <[email-masked]>
Date: Fri, 1 Apr 2016 08:27:03 -0400

> On Apr 01, 2016, at 01:07, Dave Garrett <[email-masked]> wrote:
> 
> handwaves an informational RFC to standards track (RFC5289: ECC AES GCM)

This bit we “fix” by including what’s called a “DOWNREF" in the IETF LC, as per RFC 3967. 

spt

---

From: Peter Bowen <[email-masked]>
Date: Fri, 1 Apr 2016 06:31:35 -0700

On Thu, Mar 31, 2016 at 6:19 PM, Sean Turner <[email-masked]> wrote:
>
> 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.

I'm not a fan of this option simply because
draft-ietf-tls-negotiated-ff-dhe has been stuck is MISSREF state in
the RFC editor queue for months waiting on this draft.  I don't think
there is any question the ffdhe draft is forward looking and I, for
one, would like to see it published before TLS 1.3.

Thanks,
Peter

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 Apr 2016 13:00:13 -0300

> ciphersuite (or a current one, being re-evaluated in the future) with

The issue isn't primarily the ciphers themselves, it's the security
properties of False Start. Specifically, TLS  is intended to allow a client
and server to negotiate the most preferred joint cipher suite, even if they
also support weaker cipher suites, even in the face of active attack [0].
In TLS 1.2, this guarantee is enforced by the Finished messages and
therefore the client isn't able to verify it at the time it sends its
second flight [1]. Thus, when you are doing False Start, the client has no
guarantee that an attacker hasn't forced him into a much weaker cipher
suite (potentially the weakest cipher suite that the client supports). Of
course, the handshake won't complete, but the client will have already sent
data under the weaker cipher suite.

The restrictions here are targeted at minimizing the exposure due to
potentially negotiating weaker ciphers with the general idea being that the
weakest cipher acceptable for false start is not too far away from the best
cipher. So, it's not really practical to pair it to specific cipher
properties.

-Ekr

[0] Note, this protection starts to break down if the weakest joint cipher
suite is really weak.
[1] This is why TLS 1.3 signs the entire server's second flight and why
False Start is redundant in TLS 1.3.

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 6 Apr 2016 17:01:53 +0100

Hiya,

ekr, Sean and Joe convinced me #2 below wasn't really
needed. And I don't much care what the WG conclude wrt
#1 (and we can fix later if needed), so I've requested
IETF LC to start for this.

Thanks,
S.

On 23/03/16 15:14, Stephen Farrell wrote:
> 
> 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
> 
> 
>