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

[Eric Rescorla <[e-mail]>]

On Fri, Apr 1, 2016 at 7:19 AM, Stephen Farrell <[e-mail]>
wrote:

>
> > 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.
>

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.

>
> 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
> >> [e-mail] https://www.ietf.org/mailman/listinfo/tls
> >
> >
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>