Re: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites
On Monday 21 December 2015 14:54:23 Brian Smith wrote: > Eric Rescorla wrote: > > Sorry, I'm still confused TLS 1.2 uses a specific PRF. TLS 1.3 uses > > HKDF. Are you suggesting TLS 1.2 use the TLS 1.2 PRF with SHA-512 > > and that TLS 1.2 use SHA-512 with HKDF, or something different? > > I mean that TLS 1.2 should use SHA-512 with the TLS 1.2 PRF and that > TLS 1.3 should use SHA-512 with HKDF. > > > Nobody should pay attention to what the MTI cipher suite for TLS 1.2 > > is,> > >> because it's obsolete; in fact, one would be making a huge mistake > >> to > >> deploy it now if one's application didn't have legacy backward > >> compatibility concerns. And, we should change the MTI cipher suite > >> for TLS 1.3 to the ChaCha20-Poly1305 ones, because they solve a > >> lot of problems. For example, they remove any question of any need > >> to implement rekeying, they avoid the weird IV construction hacks > >> that are necessary for 128-bit cipher suites like AES-GCM, and > >> they can be implemented efficiently in a safe way, unlike AES-GCM. > > > > This seems like a separate question. > > You are the one that brought the MTI stuff into this, not me. > > > SHA-256-using cipher suites are widely deployed and not going away > > any time soon, so what resource are you trying to conserve here? > I'm trying to minimize the number of algorithms (amount of code) > necessary to implement ChaCha20-Poly1305 using x25519 for key > agreement and Ed25519 for signatures. The different between needing > or not needing SHA-256 matters most for very small computers (AVR and > Cortex-M0), but doesn't really matter much for larger computers where > SHA-256 has an advantage. > > In particular, since there seems to be a notable amount of hardware > that is or will soon be released that optimized for > ChaCha20-Poly1305+x25519+Ed25519, because of Apple HomeKit, it would > be nice to take advantage of that for TLS. > > Besides that, the inconsistency regarding why these new > 256-bit-encryption-key cipher suites are currently defined to use > SHA-256 in the PRF whereas all the existing 256-bit-encryption-key > cipher suites use SHA-384 seems strange. Even if an application wants > to use AES-GCM cipher suites, it would be able to avoid needing > SHA-256 if it implemented the AES256-GCM cipher suites instead of > AES128-GCM. I'm not convinced about SHA-512, but yes, they probably should use SHA-384 at the very least. And given that the algorithm for SHA-384 and SHA-512 is essentially the same, using just different IVs, that should be usable for highly restricted hardware, wouldn't it? I would be against SHA-512 as that would be the very first cipher that uses SHA-512 PRF in TLS1.2, making its addition/implementation much more invasive to the underlying library, OTOH, we have multiple ciphers which use SHA-384 PRF. I think I just need to remind the delay after which NSS added support for SHA-384 compared to introduction to AES-128-GCM TLS ciphers... -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic signature.asc Description: This is a digitally signed message part. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit.
Curve25519, as the name suggests, operates on 255-bit numbers. When encoded as bytes, there's obviously a 256th bit that needs to be specified. Curve25519 implementations didn't set the bit but did used to vary on how they parsed it. Some would take a 256-bit number and reduce it while others would ignore the bit completely. However, I believe that implementations have converged on ignoring it. That behaviour is specified in draft-irtf-cfrg-curves and tested via the test vectors. Currently https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3 says that implementations SHOULD reject inputs with the high-bit set. I think that should be dropped. The X25519 function is specified in terms of bytes in draft-irtf-cfrg-curves and I think the TLS spec should just use that draft. 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] draft-ietf-tls-curve25519-01: Is public key validation necessary or helpful?
The current draft [1] says: Other than this recommended check, implementations do not need to ensure that the public keys they receive are legitimate: this is not necessary for security with Curve25519. However, Thai Duong (of BEAST fame, among other things) wrote that TLS 1.2 and below do seem to benefit from public key validation in "Why not validate Curve25519 public keys could be harmful" [2]. Watson Ladd had also pointed out many times on this list that TLS is one protocol where contributory behavior is required. DJB himself had also pointed out did point out that some protocols do require public key validation with Curve25519 "to ensure 'contributory' behavior" in [3]. Thus, the statement in draft-ietf-tls-curve25519-01 that "this is not necessary for security with Curve25519" in the current draft is clearly overly general and misleading. In particular, I noticed that the text in draft-ietf-tls-curve25519-01 section 2.3 focuses a lot on attacks that reveal the private key. However, what about other attacks? In particular, I think that, at the very least, the relevance or irrelevance to TLS of the key dictation attack that Thai brought up, and the need or non-need for checking that the agreed value is zero (basically the same thing), should be mentioned in the draft's security considerations. [1] https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3 [2] http://vnhacker.blogspot.com/2015/09/why-not-validating-curve25519-public.html [3] http://cr.yp.to/ecdh.html#validate Cheers, Brian -- https://briansmith.org/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] draft-ietf-tls-curve25519-01 and the X25519 significant bit.
Adam Langley wrote: > Currently > https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3 > says that implementations SHOULD reject inputs with the high-bit set. > I think that should be dropped. The X25519 function is specified in > terms of bytes in draft-irtf-cfrg-curves and I think the TLS spec > should just use that draft. First, maybe I'm overlooking something obvious, but I'm not seeing it: Why are we concerned only with whether the high bit has been set, instead of whether the public value has been reduced mod q (q == 2^255-19)? Aren't there ~19 interesting values that don't have the high bit set but which are also relevant to this issue? The draft notes that if the sender calculated the result correctly, then the result will never have the high bit set. So, then, we should have a requirement on the sender that the sender MUST NOT send a representation of its public value that has the high bit set? And, more generally, the sender MUST NOT send a representation of its public value that isn't reduced mod q. Would this be problematic to add this requirement? If we added the above requirement on senders, then it would matter less whether receivers reject values that aren't reduced mod q, as a conforming implementation would never send them, right? It seems like a good idea to reject non-reduced public values because: 1. By the argument in section 2.3, a conforming sender would never send them, so if the sender did send one, it means there's a problem with the sender of unknown severity, or an unknown attack on the wire. Either way, it's safest to bail out early. 2. Rejecting non-reduced values allows us to compare keys (after validation) by bytewise comparison and/or comparison of secure hashes of the bytes. AFAICT, this seems to matter less for x25519 and ECDH in general than it matters for signatures, but I bet that is just because I'm not creative enough to discover why it might matter for ECDH. I did give an example of why it can matter for signature public keys in [1]. It seems better to me to be cautious on the topic. [1] https://code.google.com/p/chromium/issues/detail?id=58#c9 Cheers, Brian -- https://briansmith.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 Dec 22, 2015 4:15 PM, "Brian Smith" wrote: > > The current draft [1] says: > > Other than this recommended check, implementations do > not need to ensure that the public keys they receive > are legitimate: this is not necessary for security > with Curve25519. > > However, Thai Duong (of BEAST fame, among other things) wrote that TLS 1.2 and below do seem to benefit from public key validation in "Why not validate Curve25519 public keys could be harmful" [2]. Watson Ladd had also pointed out many times on this list that TLS is one protocol where contributory behavior is required. > > DJB himself had also pointed out did point out that some protocols do require public key validation with Curve25519 "to ensure 'contributory' behavior" in [3]. Thus, the statement in draft-ietf-tls-curve25519-01 that "this is not necessary for security with Curve25519" in the current draft is clearly overly general and misleading. > > In particular, I noticed that the text in draft-ietf-tls-curve25519-01 section 2.3 focuses a lot on attacks that reveal the private key. However, what about other attacks? In particular, I think that, at the very least, the relevance or irrelevance to TLS of the key dictation attack that Thai brought up, and the need or non-need for checking that the agreed value is zero (basically the same thing), should be mentioned in the draft's security considerations. Textbook DH does not ensure contributory behavior. Applications don't implement the required checks for poorly designed protocols. If we insert checks, applications which fail to make those checks will be vulnerable, while fixing protocols closes the hole. > > [1] https://tools.ietf.org/html/draft-ietf-tls-curve25519-01#section-2.3 > [2] http://vnhacker.blogspot.com/2015/09/why-not-validating-curve25519-public.html > [3] http://cr.yp.to/ecdh.html#validate > > Cheers, > Brian > -- > https://briansmith.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 and the X25519 significant bit.
On Tue, Dec 22, 2015 at 1:36 PM, Brian Smith wrote: > First, maybe I'm overlooking something obvious, but I'm not seeing it: Why > are we concerned only with whether the high bit has been set, instead of > whether the public value has been reduced mod q (q == 2^255-19)? Aren't > there ~19 interesting values that don't have the high bit set but which are > also relevant to this issue? You're correct, but I'm trying to say that the CFRG document defines a function that operates on bytestrings so that higher-level protocols don't have to worry about things like this. I think TLS should handle the byte strings opaquely so that we have uniform behaviour for X25519/X448 and only a single place where it needs to be tested. The behaviour of X25519/X448 for non-reduced values is also specified in the CFRG document. 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 and the X25519 significant bit.
On Tue, Dec 22, 2015 at 11:59 AM, Adam Langley wrote: > You're correct, but I'm trying to say that the CFRG document defines a > function that operates on bytestrings so that higher-level protocols > don't have to worry about things like this. I think TLS should handle > the byte strings opaquely so that we have uniform behaviour for > X25519/X448 and only a single place where it needs to be tested. The > behaviour of X25519/X448 for non-reduced values is also specified in > the CFRG document. > I agree with all of that in principle. In fact, I think that most of section 2.3 should be removed in deference to the CFRG document, and only TLS-specific concerns should be given. I still think there is value in requiring senders to send their public value in the "normalized" form and for allowing (if not requiring) receivers to reject, at least, public values >= q, for the reasons I gave in my previous email. Ideally that would happen in the CFRG document. But, what is the status of the CFRG document? I've heard that it's past the point where changes will be accepted. Cheers, Brian -- https://briansmith.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 23 December 2015 at 08:51, Watson Ladd wrote: > Textbook DH does not ensure contributory behavior. Applications don't > implement the required checks for poorly designed protocols. If we insert > checks, applications which fail to make those checks will be vulnerable, > while fixing protocols closes the hole. I've done a fair bit of reading into this issue as well, finding Thai's blog posting and a few other things. As Watson says, the protocol can be designed so that it doesn't depend on the DH exchange providing contributory behaviour. We should definitely do that either way. I understand that the checks are considered onerous by some, but I still don't understand why anyone might refuse to do them. Checking that you don't get a bad output from the DH computation is a tiny piece of code that takes almost no time at all, even if you have to worry about doing it in constant time. ___ 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?
Martin Thomson wrote: > Watson Ladd wrote: > > Textbook DH does not ensure contributory behavior. Applications don't > > implement the required checks for poorly designed protocols. If we insert > > checks, applications which fail to make those checks will be vulnerable, > > while fixing protocols closes the hole. > > I've done a fair bit of reading into this issue as well, finding > Thai's blog posting and a few other things. As Watson says, the > protocol can be designed so that it doesn't depend on the DH exchange > providing contributory behaviour. We should definitely do that either > way. > TLS 1.2 and earlier versions are already defined. So, fixing the protocol is a good solution for TLS 1.3 and later, but draft-ietf-tls-curve25519 also is supposed to work for the versions that can't be fixed. > I understand that the checks are considered onerous by some, but I > still don't understand why anyone might refuse to do them. Checking > that you don't get a bad output from the DH computation is a tiny > piece of code that takes almost no time at all, even if you have to > worry about doing it in constant time. > To be clear, I'm not arguing that the draft should recommend or require such a check. Merely, I'm pointing out that we have the following contradictions that the draft doesn't resolve: 1. The draft says that Curve25519 doesn't require public key validation, full stop. 2. DJB said that Curve25519 may require public key validation for protocols that require contributory behavior. 3. Thai and Watson both said that TLS 1.2 and earlier require contributory behavior. It may be the case that TLS requires contributory behavior and point validation is still unnecessary. Or, it may be the case that TLS doesn't really require contributory behavior (though, it seems obvious to me that it does, at least for TLS 1.2 and earlier). Or, it may be the case that TLS requires contributory behavior and a check is necessary. The draft should make it clear which case we are dealing with, with a reference to the reasoning that gave us whatever conclusion is reached, but currently that is missing. Cheers, Brian -- https://briansmith.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 23 December 2015 at 10:23, Brian Smith wrote: > It may be the case that TLS requires contributory behavior and point > validation is still unnecessary. Or, it may be the case that TLS doesn't > really require contributory behavior (though, it seems obvious to me that it > does, at least for TLS 1.2 and earlier). Or, it may be the case that TLS > requires contributory behavior and a check is necessary. The draft should > make it clear which case we are dealing with, with a reference to the > reasoning that gave us whatever conclusion is reached, but currently that is > missing. My understanding is that with session hash TLS 1.2 is OK, as is 1.3. Like Watson and Thai, I think that 1.2 without session hash is not OK. That suggests that the 25519 draft should require session hash in 1.2. ___ 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?
Martin Thomson wrote: > On 23 December 2015 at 10:23, Brian Smith wrote: > > It may be the case that TLS requires contributory behavior and point > > validation is still unnecessary. Or, it may be the case that TLS doesn't > > really require contributory behavior (though, it seems obvious to me > that it > > does, at least for TLS 1.2 and earlier). Or, it may be the case that TLS > > requires contributory behavior and a check is necessary. The draft should > > make it clear which case we are dealing with, with a reference to the > > reasoning that gave us whatever conclusion is reached, but currently > that is > > missing. > > My understanding is that with session hash TLS 1.2 is OK, as is 1.3. > Like Watson and Thai, I think that 1.2 without session hash is not OK. > > That suggests that the 25519 draft should require session hash in 1.2. > If an implementation only implements ECDHE cipher suites then implementing the session hash extension is not necessary, according to RFC 7627. I believe there are also a few other factors that would implementing the session hash extension to be unnecessary. If checking that the shared value isn't zero is sufficient, and/or blacklisting the public values that DJB mentions in [1] is sufficient, either would be better than mandating the implementation of the session hash extension just for this purpose. [1] http://cr.yp.to/ecdh.html#validate Cheers, Brian -- https://briansmith.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 Tue, Dec 22, 2015 at 02:09:32PM -1000, Brian Smith wrote: > If checking that the shared value isn't zero is sufficient It should suffice, ideally with a constant-time comparison. -- Viktor. ___ 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 23 December 2015 at 11:09, Brian Smith wrote: > If an implementation only implements ECDHE cipher suites then implementing > the session hash extension is not necessary, according to RFC 7627. I It doesn't really say that as far as I can see, though I guess that you could infer that from this statement: Handshakes using Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) ciphersuites are also vulnerable if they allow arbitrary explicit curves or use curves with small subgroups. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
