Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
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 wrote: > On Thu, Dec 31, 2015 at 06:23:08AM +, 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
Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
On Wed, Dec 30, 2015 at 7:40 PM, Brian Smith wrote: > When you say "the plan," whose plan are you referring to? If you read that > whole thread, there was a lot of well-founded opposition to that plan. And, > that plan was never carried out. That is plain to see, as there was never a > draft submitted with such a change. I'm no expert on IETF processes but the draft was already in a late stage at the time when that came up and I think it was last the point for a -12? The revision that's currently in AUTH48 with the RFC Editor contains the change from MUST to MAY. > Not if the implementation doesn't implement RSA or finite-field DH. I think ekr's post, just previous, reflects my understanding here. For the vast majority of implementations, session-hash is needed because non-contributory key-exchange mechanisms will be included. If you do happen to have an implementation that only implements ECDHE with cofactor 1 curves or X25519 or X448, then I guess you could get away without implementing session hash, but I'd still implement session hash anyway. Having said that, I think I'd be fine with a TLS draft that said that the zero check should (or must) be done because I think that it should be done in general. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
On Thu, Dec 31, 2015 at 9:43 AM, Adam Langley wrote: > On Wed, Dec 30, 2015 at 7:40 PM, Brian Smith wrote: > > When you say "the plan," whose plan are you referring to? If you read > that > > whole thread, there was a lot of well-founded opposition to that plan. > And, > > that plan was never carried out. That is plain to see, as there was > never a > > draft submitted with such a change. > > I'm no expert on IETF processes but the draft was already in a late > stage at the time when that came up and I think it was last the point > for a -12? The revision that's currently in AUTH48 with the RFC Editor > contains the change from MUST to MAY. > > > Not if the implementation doesn't implement RSA or finite-field DH. > > I think ekr's post, just previous, reflects my understanding here. For > the vast majority of implementations, session-hash is needed because > non-contributory key-exchange mechanisms will be included. If you do > happen to have an implementation that only implements ECDHE with > cofactor 1 curves or X25519 or X448, then I guess you could get away > without implementing session hash, but I'd still implement session > hash anyway. > FWIW, I don't believe that it's significantly harder to implement TLS w/ session hash than TLS w/o session hash. You have to do the extension but since you can just fail any handshake in which it's not offered, this isn't that bad. What's expensive is supporting *both* session hash and non session hash (at least that's what we found in NSS). Having said that, I think I'd be fine with a TLS draft that said that > the zero check should (or must) be done because I think that it should > be done in general. > As would I. -Ekr > > Cheers > > AGL > > -- > Adam Langley a...@imperialviolet.org https://www.imperialviolet.org > > ___ > 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
Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
On 31 December 2015 at 17:54, Ilari Liusvaara wrote: > Zero checks can already be unit-tested/interop-tested just as well. What ekr said applies, but also this: Yes, you can test that a given implementation does the right checks, but you won't be checking during normal operation. If you require session-hash, then every handshake includes that check and if someone messes up, the handshake just fails. That far more visible. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
I think Watson made a good point about "omittable checks". If an implementation A "omits" this mechanism, it should fail session establishment. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: Alyssa Rowan Sent: Thursday, December 31, 2015 01:23 To: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful? smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
On Fri, Jan 01, 2016 at 06:22:00AM +1100, Martin Thomson wrote: > On 31 December 2015 at 17:54, Ilari Liusvaara > wrote: > > Zero checks can already be unit-tested/interop-tested just as well. > > > What ekr said applies, but also this: I thought the ekr's point was that if you need THS resistance, you require EMS. If you don't, not much point worrying what properties individual key exchanges have. > Yes, you can test that a given implementation does the right checks, > but you won't be checking during normal operation. If you require > session-hash, then every handshake includes that check and if someone > messes up, the handshake just fails. That far more visible. I don't think the parts that actually matter are tested in normal use. Unless you mean deimplementing entiere old TLS master secret derivation... -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
On Thu, Dec 31, 2015 at 12:20 PM, Ilari Liusvaara wrote: > On Fri, Jan 01, 2016 at 06:22:00AM +1100, Martin Thomson wrote: > > On 31 December 2015 at 17:54, Ilari Liusvaara > wrote: > > > Zero checks can already be unit-tested/interop-tested just as well. > > > > > > What ekr said applies, but also this: > > I thought the ekr's point was that if you need THS resistance, you > require EMS. If you don't, not much point worrying what properties > individual key exchanges have. > I think I was trying to say *almost* this: Namely that given that we have existing mechanisms that rely on EMS for THS resistance, and most stacks will continue to use them, then it's easier to just require EMS. > Yes, you can test that a given implementation does the right checks, > > but you won't be checking during normal operation. If you require > > session-hash, then every handshake includes that check and if someone > > messes up, the handshake just fails. That far more visible. > > I don't think the parts that actually matter are tested in normal > use. Unless you mean deimplementing entiere old TLS master secret > derivation... What I was suggesting was that: 1. Implementations which support old algorithms need to have EMS for THS resistance already. 2. Implementations which only do new algorithms can mandate EMS and not implement old derivation at all, provided we make that a rule here. -Ekr ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
On Wed, Dec 30, 2015 at 09:16:12PM -0500, Watson Ladd wrote: > On Wed, Dec 30, 2015 at 7:47 PM, Brian Smith wrote: > > Watson Ladd wrote: > > > > Actually, because the check for non-zero result can/should/is in the > > X25519/X448 functions themselves, the check for non-zero result is the least > > likely of all these possible solutions to be omitted. And, it is also the > > easiest to test. > > Failure to compute H(A, B, X25591(a, B)) would result in an > interoperability failure with any other implementation of this > ciphersuite. By contrast a zero check will not be exercised by basic > interoperability testing, nor would mandatory use of session hash. Actually, I figured out an attack. Which also breaks my original scheme (except in one rare case). A hack to break that attack would be to zero-pad the hash output to minimum of 48 bytes and then to append (prepending won't work) something nonzero (e.g the group id, that is 00 29 for X25519 and 00 30 for X448). -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
On Thu, Dec 31, 2015 at 12:23:50PM -0800, Eric Rescorla wrote: > On Thu, Dec 31, 2015 at 12:20 PM, Ilari Liusvaara > wrote: > > 2. Implementations which only do new algorithms can mandate EMS and not > implement old derivation at all, provided we make that a rule here. Well, the EMS spec already says that endpoints SHOULD abort if extension is not present if they don't want to interop with legacy implementations. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
On Thu, Dec 31, 2015 at 12:49 PM, Ilari Liusvaara wrote: > On Thu, Dec 31, 2015 at 12:23:50PM -0800, Eric Rescorla wrote: > > On Thu, Dec 31, 2015 at 12:20 PM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > 2. Implementations which only do new algorithms can mandate EMS and not > > implement old derivation at all, provided we make that a rule here. > > Well, the EMS spec already says that endpoints SHOULD abort if > extension is not present if they don't want to interop with > legacy implementations. Correct. But as you say, that's a check that you can omit. However, if you only implement the EMS derivation than (unless I'm missing something) even if you omit the check this should just result in a handshake failure. -Ekr > > -Ilari > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
On Thu, Dec 31, 2015 at 12:55:09PM -0800, Eric Rescorla wrote: > On Thu, Dec 31, 2015 at 12:49 PM, Ilari Liusvaara > wrote: > > > On Thu, Dec 31, 2015 at 12:23:50PM -0800, Eric Rescorla wrote: > > > On Thu, Dec 31, 2015 at 12:20 PM, Ilari Liusvaara < > > ilariliusva...@welho.com> > > > wrote: > > > > > > 2. Implementations which only do new algorithms can mandate EMS and not > > > implement old derivation at all, provided we make that a rule here. > > > > Well, the EMS spec already says that endpoints SHOULD abort if > > extension is not present if they don't want to interop with > > legacy implementations. > > > Correct. But as you say, that's a check that you can omit. However, if you > only > implement the EMS derivation than (unless I'm missing something) even if you > omit the check this should just result in a handshake failure. Yes, if you don't want to interop with legacy implementations, don't implement the legacy key derivation. Unfortunately, I think I figured out that client requiring ECDHE even with only NIST curves with full checking (which is contributory if that is even possible) does _not_ prevent THS attacks. So, if the protocol run on TLS does not resist THS attacks anyway somehow, you MUST require EMS. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data volume limits
Hi, * Simon Josefsson [16/12/2015 09:44:55] wrote: > I don't like re-keying. It is usually a sign that your primitives are > too weak and you are attempting to hide that fact. To me, it is similar > to discard the first X byte of RC4 output. > > If AES-GCM cannot provide confidentiality beyond 64GB (which would > surprise me somewhat), I believe we ought to be careful about > recommending it. > I unequivocally concur here. This might be a good time to point again to my existing AES-OCB draft that hasn't really seen a lot of discussion nor love lately. It expired but I've recently updated the draft (not yet uploaded to IETF as I'm waiting for implementer feedback from two particular sources). The update has something to do with how GCM is implemented in some stacks though, see: https://github.com/azet/draft-zauner-tls-aes-ocb/commit/26c2fff7808fc88bf47e5d097f2ff5ca23201029 Aaron signature.asc Description: Digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data volume limits
* Aaron Zauner [01/01/2016 07:35:26] wrote: > This might be a good time to point again to my existing AES-OCB > draft that hasn't really seen a lot of discussion nor love lately. > It expired but I've recently updated the draft (not yet uploaded > to IETF as I'm waiting for implementer feedback from two particular > sources). The update has something to do with how GCM is implemented > in some stacks though, see: > https://github.com/azet/draft-zauner-tls-aes-ocb/commit/26c2fff7808fc88bf47e5d097f2ff5ca23201029 Having said that, it's probably also a good idea for me to mention that the OCB designers point out that: ``` [...] Birthday-bound attacks (as well as good cryptographic hygine) motivate rekeying well in advance of birthday-bound concerns. In RFC 7253 we say that a given a key should be used to encrypt at most 248 blocks (about 280 terabytes). ``` -- http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#ferguson Aaron signature.asc Description: Digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Data volume limits
On Fri, Jan 01, 2016 at 08:04:11AM +0100, Aaron Zauner wrote: > * Aaron Zauner [01/01/2016 07:35:26] wrote: > > This might be a good time to point again to my existing AES-OCB > > draft that hasn't really seen a lot of discussion nor love lately. > > It expired but I've recently updated the draft (not yet uploaded > > to IETF as I'm waiting for implementer feedback from two particular > > sources). The update has something to do with how GCM is implemented > > in some stacks though, see: > > https://github.com/azet/draft-zauner-tls-aes-ocb/commit/26c2fff7808fc88bf47e5d097f2ff5ca23201029 > > Having said that, it's probably also a good idea for me to mention > that the OCB designers point out that: > ``` > [...] > > Birthday-bound attacks (as well as good cryptographic hygine) > motivate rekeying well in advance of birthday-bound concerns. In RFC > 7253 we say that a given a key should be used to encrypt at most 248 > blocks (about 280 terabytes). > ``` -- http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#ferguson > > Aaron On topic of existing recomendations, SECSH recommends rekeying after 2^32 blocks (64GB) with 128-bit block ciphers like AES[1]. This is obviously a lot more conservative than the above quoted recommendation. Also, it occurs to me that if key update makes sense to even include depends on the decided threshold. If it is 64GB, then it makes sense to include. If it is 256TB, then probably not (pseudo- wrapping TLS sequence numbers is probably not a good usecase, as data volumes would need to be enormous for that to become an issue). [1] It also has recommendation to rekey before 2^32 packets, but that comes from SSH sequence numbers being 32-bit. TLS sequence numbers are 64-bit. -Ilari ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
