I'm finding myself a bit unclear on the scenario people are concerned about.
It seems like there are two potential cases: 1. You have an implementation which already does some of the algorithms we know are susceptible to THS-type attacks. 2. You have an implementation which only does the CFRG curves. In the first case, if you are in a scenario where THS is relevant, then you should be insisting on session hash for the existing algorithms and so it's simplest to just always insist on session hash. And if you're failing to do so, then it's not clear to me how having the CFRG curves be safe here helps (it might be true, but I haven't convinced myself of it.) In a previous thread, Brian suggested an implementation that was just CFRG curves, so perhaps that's the scenario of interest? But in that case you can just *only* implement session hash. Specifically, you insist on negotiating the extension but only implement the session hash key derivation, rather than the normal key derivation, so there's not really a check to omit [0]. Am I missing something? -Ekr [0] This is effectively how 1.3 behaves by just always requiring session hash. On Wed, Dec 30, 2015 at 10:54 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
