On Thu, Dec 31, 2015 at 06:23:08AM +0000, Alyssa Rowan wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 2015-12-31 03:30, Adam Langley wrote: > > > I don't mind if the integration of curve25519 in TLS requires a > > zero-check or not, but what property are people hoping to gain? If > > one wants to avoid triple-handshake like issues then session-hash > > is the answer. > > (I have a terrible cold, so apologies if I am less than coherent!) > > I think I prefer this, of the available options. Specify that: > > • Both client and server MUST abort if X25519 and/or X448 are > offered/chosen but session_hash is not; > • Explain why in Security Considerations; > • Test as part of interop/unit tests? > > Zero checks are more likely to be omitted in practice because all the > implementations out there already do that and don't return a value. > And it's not something the peer would notice in normal operation.
The problems with this: The THS check is a check. Zero checks can already be unit-tested/interop-tested just as well. If you do anything that is vulernable to THS, you better take severe countermeasures at application layer (check for EMS, mix in certs, refuse resumption, dump and hash transcripts, etc...) already. As for reliability of using ECDHE... I wouldn't rely that random implementation of ECDHE is safe against THS, even with cofactor 1 Weierstrass curves. And unit-testing/interop-testing some of the issues involved is just plain nasty. > Watson's approach might work too, but of the available options I think > ensuring the transcript is hashed is the most robust with respect to > any future attacks. Actually, I proposed something very similar, but without a hash (HMAC would likely hash that thing anyway[1]). That one does not have any checks. [1] Specifically, unless X25519 is used with ciphersuite with SHA-384 as PRF-hash. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
