Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
On Tue, Jan 2, 2024 at 8:31 PM Eric Rescorla wrote: > > > On Tue, Jan 2, 2024 at 8:17 PM Benjamin Kaduk 40akamai@dmarc.ietf.org> wrote: > >> On Tue, Jan 02, 2024 at 07:17:44PM -0800, Eric Rescorla wrote: >> > >> >The issue I am concerned about is that: >> >1. Implementors who do not want to upgrade to TLS 1.3 will implement >> new >> >cipher suites >> >2. IANA will refuse to register the new cipher suites >> >With the result being potential code point collisions. >> >> I share this concern. >> > > In the interest of clarity, I favor the WG declining to work on extending > TLS 1.2, so these cipher suites should be marked as Recommended=No. I'm > just concerned that closing the registries entirely will not have the best > results. > Yes, this way seems to reflect the spirit of the IETF. That course of action may not enjoy consensus, but we should still welcome a description. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
>On Wed, Jan 3, 2024, at 15:30, Eric Rescorla wrote: >> In the interest of clarity, I favor the WG declining to work on >> extending TLS 1.2, so these cipher suites should be marked as >> Recommended=No. I'm just concerned that closing the registries entirely >> will not have the best results. > > This is also my view. It would be a shame to embark on another attempt > to use registry policies to control implementations, in defiance of > everything we've learned about that not working. I concur. (Except that I'd pick a word stronger and more descriptive than "shame". ;) smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
On Wed, Jan 3, 2024, at 15:30, Eric Rescorla wrote: > In the interest of clarity, I favor the WG declining to work on > extending TLS 1.2, so these cipher suites should be marked as > Recommended=No. I'm just concerned that closing the registries entirely > will not have the best results. This is also my view. It would be a shame to embark on another attempt to use registry policies to control implementations, in defiance of everything we've learned about that not working. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
On Tue, Jan 2, 2024 at 8:17 PM Benjamin Kaduk wrote: > On Tue, Jan 02, 2024 at 07:17:44PM -0800, Eric Rescorla wrote: > >On Tue, Jan 2, 2024 at 5:02 PM Rob Sayre <[1]say...@gmail.com> wrote: > > > > It might be better to describe TLS 1.2 as "overtaken by events". If > you > > want to use CSS Grid or Swift UI (name any newish thing), you'll > find > > yourself with a stack that supports TLS 1.3, so there's no need to > > bother with TLS 1.2 in those cases. Turning off TLS 1.2 is > sometimes a > > good idea, because that traffic is composed of undesirable bots in > many > > cases. > > I know people also work on things that are old, but it seems ok to > call > > them really old, because that is true. No one seems to disagree with > > this point in the draft: "TLS 1.3 [TLS13] is also in widespread use > and > > fixes most known deficiencies with TLS 1.2". > > If you think this draft is so strict that it will be ignored, you > have > > nothing to worry about. > > > >The issue I am concerned about is that: > >1. Implementors who do not want to upgrade to TLS 1.3 will implement > new > >cipher suites > >2. IANA will refuse to register the new cipher suites > >With the result being potential code point collisions. > > I share this concern. > In the interest of clarity, I favor the WG declining to work on extending TLS 1.2, so these cipher suites should be marked as Recommended=No. I'm just concerned that closing the registries entirely will not have the best results. -Ekr -Ben > > ___ > 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] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
On Tue, Jan 02, 2024 at 07:17:44PM -0800, Eric Rescorla wrote: >On Tue, Jan 2, 2024 at 5:02 PM Rob Sayre <[1]say...@gmail.com> wrote: > > It might be better to describe TLS 1.2 as "overtaken by events". If you > want to use CSS Grid or Swift UI (name any newish thing), you'll find > yourself with a stack that supports TLS 1.3, so there's no need to > bother with TLS 1.2 in those cases. Turning off TLS 1.2 is sometimes a > good idea, because that traffic is composed of undesirable bots in many > cases. > I know people also work on things that are old, but it seems ok to call > them really old, because that is true. No one seems to disagree with > this point in the draft: "TLS 1.3 [TLS13] is also in widespread use and > fixes most known deficiencies with TLS 1.2". > If you think this draft is so strict that it will be ignored, you have > nothing to worry about. > >The issue I am concerned about is that: >1. Implementors who do not want to upgrade to TLS 1.3 will implement new >cipher suites >2. IANA will refuse to register the new cipher suites >With the result being potential code point collisions. I share this concern. -Ben ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
On Tue, Jan 2, 2024 at 5:02 PM Rob Sayre wrote: > It might be better to describe TLS 1.2 as "overtaken by events". If you > want to use CSS Grid or Swift UI (name any newish thing), you'll find > yourself with a stack that supports TLS 1.3, so there's no need to bother > with TLS 1.2 in those cases. Turning off TLS 1.2 is sometimes a good idea, > because that traffic is composed of undesirable bots in many cases. > > I know people also work on things that are old, but it seems ok to call > them really old, because that is true. No one seems to disagree with this > point in the draft: "TLS 1.3 [TLS13] is also in widespread use and fixes > most known deficiencies with TLS 1.2". > > If you think this draft is so strict that it will be ignored, you have > nothing to worry about. > The issue I am concerned about is that: 1. Implementors who do not want to upgrade to TLS 1.3 will implement new cipher suites 2. IANA will refuse to register the new cipher suites With the result being potential code point collisions. -Ekr > > thanks, > Rob > > > > > On Tue, Jan 2, 2024 at 1:19 PM Martin Thomson wrote: > >> On Wed, Jan 3, 2024, at 01:20, Salz, Rich wrote: >> > That is not what the just-adopted draft says. It says that except for >> > ALPN and exporters that no new registrations will be accepted for TLS >> > 1.2 and that new entries should have a Note comment that says “for TLS >> > 1.3 or later”. This is a change in the current policy. It has always >> > said this; see page 3 of [1]. >> >> I should learn to read the IANA considerations. This current says: >> >> > IANA will stop accepting registrations for any TLS parameters >> [TLS13REG] except for the following >> >> Aside from the fact that the wording also says that IANA will stop >> accepting TLS 1.3 registrations too, I think that this is a very bad idea. >> > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
Salz, Rich writes: > My starting assumption here is that the majority of people implementing > TLS and/or deciding what to authorize for deployment TLS-wise, are not > stupid, and understand the benefits of the newer protocol version, > including its added security. And capable of evaluating the risks of > moving to TLS 1.3 vs. staying with 1.2. > >That is a much nicer and broader brush than one I am willing to use to paint >the IT industry. The near-universal thing I've run into is "our customers have read about this thing called TLS 1.3. 3 is bigger than 2 and they want some 3". Seriously. More generally, the request is phrased as "our customers are saying that our X can't talk to their Y. We need to make our X talk to their Y" (Y could be a 20-year-old buggy version of SSH, it's not necessarily newer stuff, just stuff that isn't currently handled). Technically the "capable of evaluating the risks" is accurate in that if they don't get some 3 there's the real risk that their customers will complain, but that's probably not what the OP was thinking about. Peter. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
This draft will likely be ignored, except by the Web browser crowd, Swift UI, and such ilk. One problem with this draft is that such “fanatical/extremist” documents diminish credibility of the body that sanctioned them in the eyes of those who deal with “real” equipment (again, excluding stuff used to connect to YouTube or Amazon). -- V/R, Uri There are two ways to design a system. One is to make it so simple there are obviously no deficiencies. The other is to make it so complex there are no obvious deficiencies. - C. A. R. Hoare From: TLS on behalf of Rob Sayre Date: Tuesday, January 2, 2024 at 20:03 To: Martin Thomson Cc: "TLS@ietf.org" Subject: Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze' It might be better to describe TLS 1. 2 as "overtaken by events". If you want to use CSS Grid or Swift UI (name any newish thing), you'll find yourself with a stack that supports TLS 1. 3, so there's no need to bother with TLS ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside the Laboratory. ZjQcmQRYFpfptBannerEnd It might be better to describe TLS 1.2 as "overtaken by events". If you want to use CSS Grid or Swift UI (name any newish thing), you'll find yourself with a stack that supports TLS 1.3, so there's no need to bother with TLS 1.2 in those cases. Turning off TLS 1.2 is sometimes a good idea, because that traffic is composed of undesirable bots in many cases. I know people also work on things that are old, but it seems ok to call them really old, because that is true. No one seems to disagree with this point in the draft: "TLS 1.3 [TLS13] is also in widespread use and fixes most known deficiencies with TLS 1.2". If you think this draft is so strict that it will be ignored, you have nothing to worry about. thanks, Rob On Tue, Jan 2, 2024 at 1:19 PM Martin Thomson wrote: On Wed, Jan 3, 2024, at 01:20, Salz, Rich wrote: > That is not what the just-adopted draft says. It says that except for > ALPN and exporters that no new registrations will be accepted for TLS > 1.2 and that new entries should have a Note comment that says “for TLS > 1.3 or later”. This is a change in the current policy. It has always > said this; see page 3 of [1]. I should learn to read the IANA considerations. This current says: > IANA will stop accepting registrations for any TLS parameters [TLS13REG] > except for the following Aside from the fact that the wording also says that IANA will stop accepting TLS 1.3 registrations too, I think that this is a very bad idea. smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
It might be better to describe TLS 1.2 as "overtaken by events". If you want to use CSS Grid or Swift UI (name any newish thing), you'll find yourself with a stack that supports TLS 1.3, so there's no need to bother with TLS 1.2 in those cases. Turning off TLS 1.2 is sometimes a good idea, because that traffic is composed of undesirable bots in many cases. I know people also work on things that are old, but it seems ok to call them really old, because that is true. No one seems to disagree with this point in the draft: "TLS 1.3 [TLS13] is also in widespread use and fixes most known deficiencies with TLS 1.2". If you think this draft is so strict that it will be ignored, you have nothing to worry about. thanks, Rob On Tue, Jan 2, 2024 at 1:19 PM Martin Thomson wrote: > On Wed, Jan 3, 2024, at 01:20, Salz, Rich wrote: > > That is not what the just-adopted draft says. It says that except for > > ALPN and exporters that no new registrations will be accepted for TLS > > 1.2 and that new entries should have a Note comment that says “for TLS > > 1.3 or later”. This is a change in the current policy. It has always > > said this; see page 3 of [1]. > > I should learn to read the IANA considerations. This current says: > > > IANA will stop accepting registrations for any TLS parameters [TLS13REG] > except for the following > > Aside from the fact that the wording also says that IANA will stop > accepting TLS 1.3 registrations too, I think that this is a very bad idea. > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
On Wed, Jan 3, 2024, at 01:20, Salz, Rich wrote: > That is not what the just-adopted draft says. It says that except for > ALPN and exporters that no new registrations will be accepted for TLS > 1.2 and that new entries should have a Note comment that says “for TLS > 1.3 or later”. This is a change in the current policy. It has always > said this; see page 3 of [1]. I should learn to read the IANA considerations. This current says: > IANA will stop accepting registrations for any TLS parameters [TLS13REG] > except for the following Aside from the fact that the wording also says that IANA will stop accepting TLS 1.3 registrations too, I think that this is a very bad idea. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
Most people in the positions you describe are not experts themselves, but rely on the recommendations and analysis of prominent industry groups because they know that that is likely to produce better answers than every IT practitioner trying to determine the answer themselves. Agree, in general. The best and brightest will say “what has the TLS working group at IETF said about this important topic?” Which is why it is useful for us to provide high quality analysis and practical guidance about how we think any upcoming transition(s) and upgrade(s) will go. And why it is important that we get it right … And I don’t think we did. TNX From: TLS On Behalf Of Salz, Rich Sent: Tuesday, January 2, 2024 10:06 AM To: Blumenthal, Uri - 0553 - MITLL Cc: TLS@ietf.org Subject: Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze' My starting assumption here is that the majority of people implementing TLS and/or deciding what to authorize for deployment TLS-wise, are not stupid, and understand the benefits of the newer protocol version, including its added security. And capable of evaluating the risks of moving to TLS 1.3 vs. staying with 1.2. That is a much nicer and broader brush than one I am willing to use to paint the IT industry. smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
Most people in the positions you describe are not experts themselves, but rely on the recommendations and analysis of prominent industry groups because they know that that is likely to produce better answers than every IT practitioner trying to determine the answer themselves. The best and brightest will say “what has the TLS working group at IETF said about this important topic?” Which is why it is useful for us to provide high quality analysis and practical guidance about how we think any upcoming transition(s) and upgrade(s) will go. And why it is important that we get it right … -Tim From: TLS On Behalf Of Salz, Rich Sent: Tuesday, January 2, 2024 10:06 AM To: Blumenthal, Uri - 0553 - MITLL Cc: TLS@ietf.org Subject: Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze' My starting assumption here is that the majority of people implementing TLS and/or deciding what to authorize for deployment TLS-wise, are not stupid, and understand the benefits of the newer protocol version, including its added security. And capable of evaluating the risks of moving to TLS 1.3 vs. staying with 1.2. That is a much nicer and broader brush than one I am willing to use to paint the IT industry. smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
I agree that IANA registrations aren't a great place to constrain this. First, constraining the registry for TLS 1.2 and not DTLS 1.2 makes a lot of things very weird. For a feature that's TLS/DTLS-agnostic, like post-quantum, it helps no one to define it for DTLS 1.2 and not TLS 1.2. Most of the code and specification work is shared. Realistically, whether or not we formally freeze DTLS 1.2, we shouldn't post-quantum for DTLS 1.2. Part of the PQ transition for DTLS will be to get folks to DTLS 1.3. (Indeed Chrome uses DTLS for WebRTC and has not yet implemented DTLS 1.3, yet I have no interest in PQ for DTLS 1.2. For WebRTC PQ, we'll just do DTLS 1.3 first.) I expect the DTLS waffling is transitory and attitudes to DTLS 1.2 vs 1.3 will catch up to TLS 1.2 vs 1.3 soon enough. But, while we're in that state, something as rigid as an IANA restriction is awkward. Second, while we don't intend to define new features for TLS 1.2, the draft says we may still apply "urgent security fixes". Restricting the IANA registration also restricts our ability to do that. Realistically, anything that involves a new extension will run into the usual considerations around existing TLS 1.2 servers not implementing it. But I could imagine, if we find another 3SHAKE, maybe deciding it's worth doing another EMS? (Maybe?? Honestly I'd probably just say, since you need a protocol change anyway, the fix is TLS 1.3.) On Tue, Jan 2, 2024 at 12:16 PM Eric Rescorla wrote: > On Tue, Jan 2, 2024 at 6:20 AM Salz, Rich wrote: > >> I'm not Martin, but I believe that his point is that both TLS >> ciphersuites and TLS supported groups/EC curves permit registration outside >> of the IETF process based on the existence of.a specification. As long as >> PQC can fit into new ciphersuites and group types, then anyone can specify >> it for TLS 1.2, and it would in fact be TLS, just not standardized or >> Recommended. >> >> >> >> That is not what the just-adopted draft says. It says that except for >> ALPN and exporters that no new registrations will be accepted for TLS 1.2 >> and that new entries should have a Note comment that says “for TLS 1.3 or >> later”. This is a change in the current policy. It has always said this; >> see page 3 of [1]. >> > > I agree that's clear. Not sure how I misunderstood that, but in that case, > I think that this may be going too far, for the usual reasons why it's not > helpful to restrict IANA registrations of new stuff. > > Don't we expect this just to result in squatting. > > -Ekr > > >> >> >> At the last meeting we decided NOT to freeze DTLS 1.2 since DTLS 1.3 has >> so little deployment[4]. This has complicated the wording of the above >> statement, which was raised at [2] and [3] >> >> >> >> [1] >> https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-new-draft-tls-12-is-frozen-00 >> >> [2] https://github.com/richsalz/tls12-frozen/issues/10 >> >> [3] https://github.com/richsalz/tls12-frozen/pull/13 >> >> [4] https://datatracker.ietf.org/doc/minutes-118-tls-202311060830/ >> >> >> >> >> > ___ > 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] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
On Tue, Jan 2, 2024 at 6:20 AM Salz, Rich wrote: > I'm not Martin, but I believe that his point is that both TLS ciphersuites > and TLS supported groups/EC curves permit registration outside of the IETF > process based on the existence of.a specification. As long as PQC can fit > into new ciphersuites and group types, then anyone can specify it for TLS > 1.2, and it would in fact be TLS, just not standardized or Recommended. > > > > That is not what the just-adopted draft says. It says that except for > ALPN and exporters that no new registrations will be accepted for TLS 1.2 > and that new entries should have a Note comment that says “for TLS 1.3 or > later”. This is a change in the current policy. It has always said this; > see page 3 of [1]. > I agree that's clear. Not sure how I misunderstood that, but in that case, I think that this may be going too far, for the usual reasons why it's not helpful to restrict IANA registrations of new stuff. Don't we expect this just to result in squatting. -Ekr > > > At the last meeting we decided NOT to freeze DTLS 1.2 since DTLS 1.3 has > so little deployment[4]. This has complicated the wording of the above > statement, which was raised at [2] and [3] > > > > [1] > https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-new-draft-tls-12-is-frozen-00 > > [2] https://github.com/richsalz/tls12-frozen/issues/10 > > [3] https://github.com/richsalz/tls12-frozen/pull/13 > > [4] https://datatracker.ietf.org/doc/minutes-118-tls-202311060830/ > > > > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
My starting assumption here is that the majority of people implementing TLS and/or deciding what to authorize for deployment TLS-wise, are not stupid, and understand the benefits of the newer protocol version, including its added security. And capable of evaluating the risks of moving to TLS 1.3 vs. staying with 1.2. That is a much nicer and broader brush than one I am willing to use to paint the IT industry. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
>jQcmQRYFpfptBannerEnd >> Those who can move to 1.3+, will do so, regardless of this draft. Those who >>can’t, would >> do whatever’s appropriate in their case – again, regardless of this draft. > > Same as for any other IETF document. :) :-) Yes, but not quite – as other IETF documents (usually) provide more of (IMHO) useful information. This one is (IMHO) a pure attempt of “legal spit”. > One difference in the current wording is that it would become trivially more >difficult to get a multi-vendor > PQ solution for current TLS 1.2 implementations. Yeah, a great accomplishment, indeed. Authors can be proud. :-( > Assuming, of course, that “just use what was defined for TLS 1.3 or later” > somehow > doesn’t occur to everyone. My starting assumption here is that the majority of people implementing TLS and/or deciding what to authorize for deployment TLS-wise, are not stupid, and understand the benefits of the newer protocol version, including its added security. And capable of evaluating the risks of moving to TLS 1.3 vs. staying with 1.2. With the additional advantage of being aware of their CONOPS- and use-case-specific circumstances. I have seen real (and important enough) cases where that kind of upgrade was infeasible, so the authorities chose to “accept the risk”. (And no, I cannot post details – so no need to bother asking.) TNX smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
On Tue, Jan 2, 2024 at 3:30 PM Salz, Rich wrote: > Those who can move to 1.3+, will do so, regardless of this draft. Those > who can’t, would do whatever’s appropriate in their case – again, > regardless of this draft. > > > > Same as for any other IETF document. :) > > > > One difference in the current wording is that it would become trivially > more difficult to get a multi-vendor PQ solution for current TLS 1.2 > implementations. Assuming, of course, that “just use what was defined for > TLS 1.3 or later” somehow doesn’t occur to everyone. > It is more difficult than "just use what was defined for TLS 1.3 or later". TLS 1.2 has a downgrade attack where a MitM can force a broken commonly supported group even if the handshake signature is secure/PQ (CurveSwap). TLS 1.3 fixed that. I do have to add that the scope (I can imagine now) is limited: it affects clients that can disable classical authentication, but cannot disable classical key agreement everywhere. Best, Bas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
Those who can move to 1.3+, will do so, regardless of this draft. Those who can’t, would do whatever’s appropriate in their case – again, regardless of this draft. Same as for any other IETF document. :) One difference in the current wording is that it would become trivially more difficult to get a multi-vendor PQ solution for current TLS 1.2 implementations. Assuming, of course, that “just use what was defined for TLS 1.3 or later” somehow doesn’t occur to everyone. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
>> I'm not Martin, but I believe that his point is that both TLS ciphersuites >>and TLS supported groups/EC curves >> permit registration outside of the IETF process based on the existence of.a >> specification. As long as PQC can >> fit into new ciphersuites and group types, then anyone can specify it for >> TLS 1.2, and it would in fact be >> TLS, just not standardized or Recommended. > > That is not what the just-adopted draft says. It says that except for ALPN > and exporters that no new > registrations will be accepted for TLS 1.2 and that new entries should have a > Note comment that says > “for TLS 1.3 or later”. This is a change in the current policy. It has > always said this; see page 3 of [1]. Which is why this “just-adopted draft” is misguided and will probably be ignored in the field. Those who can move to 1.3+, will do so, regardless of this draft. Those who can’t, would do whatever’s appropriate in their case – again, regardless of this draft. > At the last meeting we decided NOT to freeze DTLS 1.2 since DTLS 1.3 has so > little deployment[4]. > This has complicated the wording of the above statement, which was raised at > [2] and [3] [1] https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-new-draft-tls-12-is-frozen-00 [2] https://github.com/richsalz/tls12-frozen/issues/10 [3] https://github.com/richsalz/tls12-frozen/pull/13 [4] https://datatracker.ietf.org/doc/minutes-118-tls-202311060830/ smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
I'm not Martin, but I believe that his point is that both TLS ciphersuites and TLS supported groups/EC curves permit registration outside of the IETF process based on the existence of.a specification. As long as PQC can fit into new ciphersuites and group types, then anyone can specify it for TLS 1.2, and it would in fact be TLS, just not standardized or Recommended. That is not what the just-adopted draft says. It says that except for ALPN and exporters that no new registrations will be accepted for TLS 1.2 and that new entries should have a Note comment that says “for TLS 1.3 or later”. This is a change in the current policy. It has always said this; see page 3 of [1]. At the last meeting we decided NOT to freeze DTLS 1.2 since DTLS 1.3 has so little deployment[4]. This has complicated the wording of the above statement, which was raised at [2] and [3] [1] https://datatracker.ietf.org/meeting/117/materials/slides-117-tls-new-draft-tls-12-is-frozen-00 [2] https://github.com/richsalz/tls12-frozen/issues/10 [3] https://github.com/richsalz/tls12-frozen/pull/13 [4] https://datatracker.ietf.org/doc/minutes-118-tls-202311060830/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
On Mon, Jan 1, 2024 at 7:05 PM Rob Sayre wrote: > Martin, > > You haven’t formed a complete sentence here. That’s usually allowable, but > not in this instance. > > Uri said there might be “special cases”. Anyone can make TLS 1.2 PQ, it > just won’t be called TLS. > I'm not Martin, but I believe that his point is that both TLS ciphersuites and TLS supported groups/EC curves permit registration outside of the IETF process based on the existence of.a specification. As long as PQC can fit into new ciphersuites and group types, then anyone can specify it for TLS 1.2, and it would in fact be TLS, just not standardized or Recommended. -Ekr > thanks, > Rob > > On Mon, Jan 1, 2024 at 17:56 Martin Thomson wrote: > >> >> >> On Fri, Dec 22, 2023, at 10:23, Salz, Rich wrote: >> > Of course. We’re not the protocol police and nobody from the IETF will >> > come and arrest anyone who uses Kyber-based key exchange in TLS 1.2 But >> > with this document, they will not be able to register such an algorithm >> > for 1.2 >> >> I don’t think we can go that far. Our registry policies would allow >> someone else to define something PQC-ish we are only saying that we >> .intend. to not define something with “official” standing. >> >> ___ >> 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] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
Martin, You haven’t formed a complete sentence here. That’s usually allowable, but not in this instance. Uri said there might be “special cases”. Anyone can make TLS 1.2 PQ, it just won’t be called TLS. thanks, Rob On Mon, Jan 1, 2024 at 17:56 Martin Thomson wrote: > > > On Fri, Dec 22, 2023, at 10:23, Salz, Rich wrote: > > Of course. We’re not the protocol police and nobody from the IETF will > > come and arrest anyone who uses Kyber-based key exchange in TLS 1.2 But > > with this document, they will not be able to register such an algorithm > > for 1.2 > > I don’t think we can go that far. Our registry policies would allow > someone else to define something PQC-ish we are only saying that we > .intend. to not define something with “official” standing. > > ___ > 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] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
On Fri, Dec 22, 2023, at 10:23, Salz, Rich wrote: > Of course. We’re not the protocol police and nobody from the IETF will > come and arrest anyone who uses Kyber-based key exchange in TLS 1.2 But > with this document, they will not be able to register such an algorithm > for 1.2 I don’t think we can go that far. Our registry policies would allow someone else to define something PQC-ish we are only saying that we .intend. to not define something with “official” standing. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
You can tell the reader whatever you want. The fact remains that if the only way to add QR to the currently deployed TLS-1.2-based “stuff” is modifying TLS-1.2, then that’s what will be done in that particular case. Of course. We’re not the protocol police and nobody from the IETF will come and arrest anyone who uses Kyber-based key exchange in TLS 1.2 But with this document, they will not be able to register such an algorithm for 1.2 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'
-1 to Tim. You can tell the reader whatever you want. The fact remains that if the only way to add QR to the currently deployed TLS-1.2-based “stuff” is modifying TLS-1.2, then that’s what will be done in that particular case. I hope that the majority of the installed base would be able to migrate to PQ and TLS-1.3+ in a normal way. But in all likelihood, “special cases” will exist. -- V/R, Uri There are two ways to design a system. One is to make it so simple there are obviously no deficiencies. The other is to make it so complex there are no obvious deficiencies. - C. A. R. Hoare From: TLS on behalf of Ira McDonald Date: Thursday, December 21, 2023 at 13:39 To: Tim Hollebeek , Ira McDonald Cc: Hannes Tschofenig , Bas Westerbaan , "Salz, Rich" , "TLS@ietf.org" Subject: [EXT] Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze' +1 to Tim - tell the reader explicitly that they will only ever get PQC w/ TLS 1. 3 or higher. Cheers, - Ira On Thu, Dec 21, 2023, 12: 34 PM Tim Hollebeek wrote: I personally think this point ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside the Laboratory. ZjQcmQRYFpfptBannerEnd +1 to Tim - tell the reader explicitly that they will only ever get PQC w/ TLS 1.3 or higher. Cheers, - Ira On Thu, Dec 21, 2023, 12:34 PM Tim Hollebeek wrote: I personally think this point is important enough to be made explicitly instead of implicitly. If we want to communicate loudly and clearly that post-quantum cryptography is NEVER coming to TLS 1.2, we need to explicitly say that. Otherwise people will say “I know you said TLS 1.2 was frozen, but post-quantum cryptography isn’t a feature, it’s a critical security vulnerability that needs to be patched regardless of any freezes.” The answer will be and needs to be: “No, we told you clearly and explicitly that post-quantum cryptography would require moving to TLS 1.3 or later”. -Tim From: TLS On Behalf Of Hannes Tschofenig Sent: Monday, December 11, 2023 12:06 PM To: Salz, Rich ; Hannes Tschofenig ; Bas Westerbaan ; Deirdre Connolly Cc: TLS@ietf.org Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze' Hi Rich, that is implied by a "feature freeze". No reason to highlight PQC (even though it is a hype topic right now). Ciao Hannes Am 11.12.2023 um 17:18 schrieb Salz, Rich: 1. I consider Section 3 "Implications for post-quantum cryptography" misplaced. I suggest to delete the section 2. The motivation for the draft is unrelated to developments with PQC. The point is to explain to people that we are going to need PQ crypto, and it *will not be a 1.2 enhancement* ___ 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 smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
