Re: [TLS] Bikeshedding ECHO
On Thu, May 7, 2020 at 11:00 PM Sean Turner wrote: > > > > On May 7, 2020, at 19:03, Tommy Pauly > wrote: > > > > To that end, I’d have a minor preference for “ETCH”. > > If we could just work an “a" and “sketch” into the name … I am all in. > > More seriously, let’s knock this decision out by end of next week, i.e., > the 15th. > It doesn't matter, and I don't care what it is called. Very few people on the planet know what this is, so leaving "ECHO" is fine too. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Bikeshedding ECHO
+1 to "ETCH" Any objections to that or concerns with that? (Agreed it would be good to finalize this ASAP.) On Thu, May 7, 2020 at 7:03 PM Tommy Pauly wrote: > ECHO is more fun to say, but I do see how it can be confusing (sounding > like some sort of ping) when out of the context of TLS. > > To that end, I’d have a minor preference for “ETCH”. > > Thanks, > Tommy > > > On May 7, 2020, at 3:52 PM, Christopher Wood > wrote: > > > > Erik raises some compelling reasons to change the name from ECHO to... > something else less confusing or misleading [1]. Candidates from the PR > include ETCH (Encrypted TLS Client Hello), ECH, and EHELLO. Since the > HTTPSSVC draft aims for WGLC before IETF 108, it would be good if we got > this bikeshedding out of the way now. To that end, if you have an opinion > on the name and whether or not we should change it, please share it! > > > > Thanks, > > Chris (no hat) > > > > [1] https://github.com/tlswg/draft-ietf-tls-esni/issues/232 > > > > ___ > > 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
[TLS] NIST crypto group and HKDF (and therefore TLS 1.3)
If you don’t care about FIPS-140, just delete this message, and avoid the temptation to argue how bad it is. NIST SP 800-56C (Recommendation for Key-Derivation Methods in Key-Establishment Schemes) is currently a draft in review. The document is at https://csrc.nist.gov/publications/detail/sp/800-56c/rev-2/draft Email comments can be sent to 800-56c_comme...@nist.gov with a deadline of May 15. That is not a lot of time. The NIST crypto group is currently unlikely to include HKDF, which means that TLS 1.3 would not be part of FIPS. The CMVP folks at NIST understand this, and agree that this would be bad; they are looking at adding it, perhaps via an Implementation Guidance update. If you have a view of HKDF (and perhaps TLS 1.3), I strongly encourage you to comment at the above address. Please do not comment here. I know that many members of industry and academia have been involved with TLS 1.3, and performed security analysis of it. If you are one of those people, *please* send email and ask the NIST Crypto Team to reconsider. Thank you. /r$ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] NIST crypto group and HKDF (and therefore TLS 1.3)
> -Original Message- > From: Cfrg On Behalf Of Salz, Rich > Subject: [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3) > > NIST SP 800-56C (Recommendation for Key-Derivation Methods in Key- > Establishment Schemes) is currently a draft in review with a deadline of > May 15. That is not a lot of time. The NIST crypto group is currently > unlikely > to include HKDF, which means that TLS 1.3 would not be part of FIPS. The > CMVP folks at NIST understand this, and agree that this would be bad; they > are > looking at adding it, perhaps via an Implementation Guidance update. [DB] But NIST Draft SP 800-56Cr2 cites RFC 5869, which is HKDF, and says HKDF is a version of 56C Section 5.1. So, I had thought that 56C would allow HKDF. What am I missing? -- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] NIST crypto group and HKDF (and therefore TLS 1.3)
>[DB] But NIST Draft SP 800-56Cr2 cites RFC 5869, which is HKDF, and says > HKDF is a version of 56C Section 5.1. So, I had thought that 56C would allow HKDF. What am I missing? It cites it, but doesn't include it in the 800-56 doc. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] NIST crypto group and HKDF (and therefore TLS 1.3)
> -Original Message- > From: Salz, Rich > > >[DB] But NIST Draft SP 800-56Cr2 cites RFC 5869, which is HKDF, and > > says > HKDF > is a version of 56C Section 5.1. So, I had thought that 56C would allow > HKDF. > What am I missing? > > It cites it, but doesn't include it in the 800-56 doc. To be clear, are you saying that RFC 5869 HKDF is not compatible with 800-56Cr2? (I had assumed they were compatible, but just used different notation for the same idea.) Looking just now, I see 800-56C refers to 800-108, whose Section 5.2, KDF in Feedback Mode looks really close to HKDF in RFC 5869. I see the same overall design, but some different orderings of inputs, which could cause non-interop. Is that the case? -- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] NIST crypto group and HKDF (and therefore TLS 1.3)
On Fri, May 8, 2020, at 17:08, Salz, Rich wrote: > It cites it, but doesn't include it in the 800-56 doc. Maybe I'm confused too, but it sounds like it's included to me. The definition of the KDF includes: > The first (randomness-extraction) step uses either HMAC … If > HMAC-hash is used in the randomness- extraction step, then the same > HMAC-hash (i.e., using the same hash function, hash) shall be used as > the PRF in the key-expansion step This sounds like this would allow for HKDF as defined in RFC 5869 (which as far as I can tell is the same thing except with HMAC required in both steps instead of giving you the option of using AES-CMAC), unless I've misunderstood something (not being anywhere near an expert on this topic, this is quite possible — even likely). Afterwards, it cites 5869 in such a way that sounds like it's saying that it's a subset of the approved algorithm (although "a version" is vague and confusing): > [RFC 5869] specifies a version of the above extraction-then-expansion > key-derivation procedure using HMAC for both the extraction and > expansion steps. For an extensive discussion concerning the rationale > for the extract-and-expand mechanisms specified in this > Recommendation, see [LNCS 6223]. The last citation in that paragraph to LNCS 6223 appears to give a long justification for why HKDF is secure, which all together makes it sound like HKDF is an approved algorithm and thus TLS 1.3 will be okay. —Sam -- Sam Whited ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Cfrg] NIST crypto group and HKDF (and therefore TLS 1.3)
Dear all. I just now noticed the call for comment for SP-800-56c. Please note the state-of-the-art paper on seedless randomness extraction in the recent CRYPTO'19 paper by Sandro Coretti, Harish Karthikeyan, Stefano Tessaro and myself: "Seedless Fruit is the Sweetest: Random Number Generation, Revisited", https://cs.nyu.edu/~dodis/ps/seedless.pdf Along its results, it strongly advises AGAINST using CBC-mode, such as AES-CMAC, for randomness extraction. It also gives very clean randomness extraction modules based on existing functions, such as SHA2 and SHA3, and also analyzes HKDF. I (and likely my co-authors, cc'ed) will be happy to work with NIST on making sure they follow state-of-the-art recommendation validated by the top conferences such as CRYPTO. I admit I did not read the document in detail, but it looks like it does not include any of the optimized constructions from our paper, but still includes (at least theoretically) insecure CMAC mode. Can somebody recommend a proper course of action if my suspicion is correct? Yevgeniy On Fri, May 8, 2020 at 4:21 PM Salz, Rich wrote: > > If you don’t care about FIPS-140, just delete this message, and avoid the > temptation to argue how bad it is. > > NIST SP 800-56C (Recommendation for Key-Derivation Methods in > Key-Establishment Schemes) is currently a draft in review. The document is at > https://csrc.nist.gov/publications/detail/sp/800-56c/rev-2/draft Email > comments can be sent to 800-56c_comme...@nist.gov with a deadline of May 15. > That is not a lot of time. The NIST crypto group is currently unlikely to > include HKDF, which means that TLS 1.3 would not be part of FIPS. The CMVP > folks at NIST understand this, and agree that this would be bad; they are > looking at adding it, perhaps via an Implementation Guidance update. > > If you have a view of HKDF (and perhaps TLS 1.3), I strongly encourage you to > comment at the above address. Please do not comment here. I know that many > members of industry and academia have been involved with TLS 1.3, and > performed security analysis of it. If you are one of those people, *please* > send email and ask the NIST Crypto Team to reconsider. > > Thank you. > /r$ > > > > ___ > Cfrg mailing list > c...@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Bikeshedding ECHO
I rather prefer ECHO. -Ekr On Fri, May 8, 2020 at 9:31 AM Erik Nygren wrote: > +1 to "ETCH" > > Any objections to that or concerns with that? > (Agreed it would be good to finalize this ASAP.) > > On Thu, May 7, 2020 at 7:03 PM Tommy Pauly 40apple@dmarc.ietf.org> wrote: > >> ECHO is more fun to say, but I do see how it can be confusing (sounding >> like some sort of ping) when out of the context of TLS. >> >> To that end, I’d have a minor preference for “ETCH”.. >> >> Thanks, >> Tommy >> >> > On May 7, 2020, at 3:52 PM, Christopher Wood >> wrote: >> > >> > Erik raises some compelling reasons to change the name from ECHO to... >> something else less confusing or misleading [1]. Candidates from the PR >> include ETCH (Encrypted TLS Client Hello), ECH, and EHELLO. Since the >> HTTPSSVC draft aims for WGLC before IETF 108, it would be good if we got >> this bikeshedding out of the way now. To that end, if you have an opinion >> on the name and whether or not we should change it, please share it! >> > >> > Thanks, >> > Chris (no hat) >> > >> > [1] https://github.com/tlswg/draft-ietf-tls-esni/issues/232 >> > >> > ___ >> > 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 > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Bikeshedding ECHO
On Fri, May 08, 2020 at 03:38:33PM -0700, Eric Rescorla wrote: > I rather prefer ECHO. Do you have some arguments to dispel the concerns about confusion, other than your personal preference? -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Bikeshedding ECHO
On Fri, May 8, 2020 at 3:43 PM Benjamin Kaduk wrote: > On Fri, May 08, 2020 at 03:38:33PM -0700, Eric Rescorla wrote: > > I rather prefer ECHO. > > Do you have some arguments to dispel the concerns about confusion, other > than > your personal preference? > There's no confusion. I couldn't believe the issue was raised (the name does not matter). thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
