On Fri, Apr 1, 2016 at 7:19 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> 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 > >> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
