Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate
FYI: This PR has been merged. Best, Chris, on behalf of the chairs On Mon, May 4, 2020, at 10:08 AM, Christopher Wood wrote: > Thanks, Alessandro! We'll aim to merge this PR on Friday. We ask that > folks review it before then. > >https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/5 > > Thanks, > Chris, on behalf of the chairs > > On Thu, Apr 23, 2020, at 10:45 AM, Alessandro Ghedini wrote: > > On Sun, Nov 24, 2019 at 11:27:26AM -0500, David Benjamin wrote: > > > On Sat, Nov 23, 2019 at 8:40 AM Ilari Liusvaara > > > wrote: > > > > > > > On Fri, Nov 22, 2019 at 08:18:47PM +0100, Hubert Kario wrote: > > > > > On Friday, 22 November 2019 03:25:24 CET, David Benjamin wrote: > > > > > > On Fri, Nov 22, 2019 at 8:35 AM Salz, Rich wrote: > > > > > > > > > > > > > > ... > > > > > > > SHA-1 signature hashes in TLS 1.2" draft available > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/. > > > > > > > Please review the document and send your comments to the list by > > > > 2359 UTC > > > > > > > on 13 December 2019. > > > > > > > > > > > > > > I just re-read this. Looks good. Perhaps a sentence of rationale > > > > > > > in > > > > ... > > > > > > > > > > > > To that end, the combination of client advice in sections 2 and 4 > > > > > > is a > > > > bit > > > > > > odd. Section 2 uses SHOULD NOT include MD5 and SHA-1, but section 4 > > > > says > > > > > > the client MUST NOT accept the MD5 SHA-1, even if it included it. > > > > > > Why > > > > would > > > > > > the client include it in that case? It seems the two should either > > > > both be > > > > > > MUST NOT or both be SHOULD NOT. > > > > > > > > > > because it also influences certificate selection, and getting a > > > > certificate > > > > > signed with SHA-1 isn't an automatically disqualifying property? > > > > > (it may be an intermediate CA that's not used, it may be an explicitly > > > > > trusted > > > > > certificate, etc.) > > > > > > > > If you don't want SHA-1 exchange signatures, you darn sure do not want > > > > actual SHA-1 certificates that are not trust anchors anyway. And because > > > > TLS 1.2 does not have separate lists for exchange signatures and > > > > certificate signatures, the client needs to withdraw advertisment for > > > > both in order to not send a misleading offer. > > > > > > > > > > Right, I had a longer discussion of the certificate-but-not-TLS case but > > > omitted it. :-) Basically what Ilari said. In particular, I believe older > > > versions of Schannel will, despite being able to sign SHA-256, > > > preferentially sign SHA-1 if the client offers it. This is inconvenient > > > when it comes to predicting breakage but is perfectly consistent with the > > > client's offer. When I last looked at this a few years ago, this accounted > > > for a nontrivial portion of SHA-1-negotiating servers on the web, so > > > rejecting SHA-1 while still advertising it is probably not the best > > > strategy. > > > > > > Fortunately, we've already distrusted SHA-1 X.509 signatures on the web, > > > so > > > hopefully that will simplify things. There is a risk that some servers' > > > trust anchors' (otherwise irrelevant) signatures are SHA-1 and they are > > > trying to match it against the signature algorithms list, but I expect the > > > SHA-1-preferring servers to be the deciding concern. Issues with > > > trust-anchor-checking servers can likely be worked around by configuring > > > the server to not send the trust anchor, which is desirable anyway. > > > > > > (All of this may not apply to non-web deployments, of course.) > > > > > > > > > > And I expect that in practice, not sending SHA-1 in > > > > signature_algorithms would cause very little breakage on top of what > > > > is already broken due to using SHA-1 exchange signatures. > > > > > > > > > > > > So I think both should be MUST NOT. > > > > So, based on this discussion, I made the following PR to change this to > > MUST NOT > > https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/5 > > > > Thanks for the review! > > > > Cheers > > > > ___ > > 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] NIST crypto group and HKDF (and therefore TLS 1.3)
Rich, Check out SP 800-52r2. Section 3.1 includes the following: servers … should be configured to negotiate TLS 1.3. and Agencies shall support TLS 1.3 by January 1, 2024. “should” and “shall” are defined in RFC 2119. One could make the case that you are already there ;} If not, then I’m going to guess that SP 800-135r1, which includes a bunch of Application-Specific KDFs (e.g., IKEv2, TLS 1.2) needs a rev. spt > On May 9, 2020, at 09:07, Salz, Rich > wrote: > > Sorry for the confusion I caused. > > HKDF is part of SP 800-56C. NIST says that what TLS 1.3 does isn't quite the > same, and therefore will not be covered by 56C. NIST wants to get TLS 1.3 > validated for FIPS, and is currently trying to figure out how to do so. The > comment period for 56C closes Friday, and getting the TLS 1.3 KDF accepted > into that is one way to get TLS 1.3 into FIPS. > > Hope this helps clear things up. > > ___ > 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] NIST crypto group and HKDF (and therefore TLS 1.3)
On Sat, May 9, 2020 at 9:08 AM Salz, Rich wrote: > > Sorry for the confusion I caused. > > HKDF is part of SP 800-56C. NIST says that what TLS 1.3 does isn't quite the same, and therefore will not be covered by 56C. NIST wants to get TLS 1.3 validated for FIPS, and is currently trying to figure out how to do so. The comment period for 56C closes Friday, and getting the TLS 1.3 KDF accepted into that is one way to get TLS 1.3 into FIPS. Well, now I'm really confused. Can't NIST look at the spec and ensure they have documents covering all parts of TLS 1.3 for FIPS? > > Hope this helps clear things up. > > ___ > 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] NIST crypto group and HKDF (and therefore TLS 1.3)
Sorry for the confusion I caused. HKDF is part of SP 800-56C. NIST says that what TLS 1.3 does isn't quite the same, and therefore will not be covered by 56C. NIST wants to get TLS 1.3 validated for FIPS, and is currently trying to figure out how to do so. The comment period for 56C closes Friday, and getting the TLS 1.3 KDF accepted into that is one way to get TLS 1.3 into FIPS. Hope this helps clear things up. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS Export Channel Binding
Hi all, After thinking about this a little more, I think we should keep the draft generic and not make it SCRAM specific. While I generally agree with Jonathan's defense-in-depth strategy, there is also value in having a direct replacement for tls-unique that can be substituted in everywhere tls-unique is used to make the upgrade path easier. If we do that, we can always add a SCRAM specific channel binding type later on and slowly start the process of upgrading the n-places that use tls- unique with protocol specific binding types. Thoughts? —Sam On Mon, May 4, 2020, at 12:56, Jonathan Hoyland wrote: > Hi Alexey > > On Mon, 4 May 2020 at 16:23, Alexey Melnikov > wrote: > > Hi Jonathan, > > > > On 04/05/2020 14:14, Jonathan Hoyland wrote: > > > Hi Sam, > > > > > > If you wanted to use a SCRAM based SASL auth then you could pick > > > `p=SCRAM-SHA256-PLUS`, or any other very specific IANA-registered > > > string, and update the SCRAM RFC to require that string with TLS > > > 1.3. You actively don't want for the same channel binding to be > > > an input to multiple different protocols (or even the same > > > protocol but with different parameters) because it opens the > > > door to confusion attacks. > > > > Can you elaborate on what you are trying to protect from? > > > > If two protocols use the same channel binding there is a risk that the > messages from one can be confused with the messages from the other. > This might happen accidentally, or an adversary might be able to forge > one from the other. If you wanted to do a formal analysis of the of > the security of TLS 1.3 > + SCRAM then a generic binding means you have to factor in what every > other possible protocol might do. If you use a unique and specific > channel binding then the analysis is far easier and can be a lot > more robust (this assumes a global coordinator of unique strings, > such as IANA). From an analysis perspective it's easier to rule out > classes of attacks than to consider all possible interactions > between all users of the interface, some of which you won't know > about, or perhaps haven't even been invented yet. > > > Historically channel bindings were constant once TLS negotiation > > was complete (they could change if TLS renegotiation happens). So > > they never depended on what was sent over the protocol above TLS. > > > > Yeah, I think the design in TLS 1.3 is much more robust, especially > from a formal analysis perspective. By constructing channel bindings > based on the parameters negotiated over the top you get a belt-and- > braces design. If you have a contributive channel binding [1] then if > the security of either the underlying protocol (in this case TLS) or > the over-the-top protocol (in this case SCRAM) fails, then the channel > binding guarantees the authentication still happened properly. > Consider the case where an adversary publishes the server's private > key to twitter. If you have a contributive channel binding then if the > SCRAM handshake succeeds you could be sure that you were talking to > the real server, and weren't being MITMed. If you don't base the > channel binding on the parameters agreed in the upper protocol it's > possible (in theory) that an adversary could compute two SCRAM > handshakes that appear to succeed, but that actually agree different > parameters. In this particular case it's not obvious how that could > happen, but it's easy to think up pathological examples, and [1] has a > few concrete examples too. > > > I've only skimmed the SCRAM RFC, but it might make sense to > > > include `client-first-message` and `server-first-message` as > > > context to the exporter interface, because it seems that the > > > channel binding isn't needed until the `client-final-message`. > > > > "the channel binding isn't needed until the `client-final-message`" > > is correct. Can you elaborate on what is problematic with this? > > Sorry if I was unclear, there's nothing problematic with this per se. > It's just that the channel binding can't be dependent on itself, but > including everything that precedes the channel binding just seems like > an easy win, esp. as (in this case) that includes all parameter > negotiation. > > > > > > The idea is to use the transcript to bind the channel binding to > > > the negotiation of SCRAM parameters, and thus allow you to define > > > a single "TLS-SASL-SCRAM" string (or whatever makes sense), > > > rather than have one for each possible set of parameters. > > > Obviously you'd need to think some more about whether that was > > > actually secure, but at first glance it seems like a reasonable > > > approach. > > > > > > Channel bindings that bind both the underlying channel and the > > > higher-level protocol make more sense to me that channel bindings > > > that only identify the underlying channel, because you don't have > > > to worry about the (potentially pathological) behaviours of
