Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Ira McDonald]

+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  40cloudflare@dmarc.ietf.org>; Deirdre Connolly <
> durumcrustu...@gmail.com>
> *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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Tim Hollebeek]

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 <mailto: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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Deirdre Connolly]

Hi all,

Thanks to everyone who chimed in on this adoption call. It looks like there
is consensus to adopt this as a WG item and volunteers to help review.
Rich, can you please submit draft-ietf-tls-tls12-frozen-00 to datatracker,
and transfer the GitHub repo to the tlswg GitHub org?
Thank you!

Cheers,
Deirdre, for the holiday chairs ✨

On Thu, Dec 14, 2023 at 6:40 AM William Stratton Apsokardu <
williamsapsokardu...@outlook.com> wrote:

> Facebook Facebook
> FacebookFacebook
> Get Outlook for iOS <https://aka.ms/o0ukef>
> --
> *From:* TLS  on behalf of Nimrod Aviram <
> nimrod.avi...@gmail.com>
> *Sent:* Wednesday, December 13, 2023 9:49:55 AM
> *To:* Ilari Liusvaara 
> *Cc:* TLS@ietf.org 
> *Subject:* Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
>
> Hi Ilari, thanks for the clarification!
>
> I attempted to correct the text.
> Would you be willing to review the change? It's here:
>
> https://github.com/richsalz/tls12-frozen/commit/a1ce7ede97897e291af44f0c2f4fc225a2ca4447
>
> thanks,
> Nimrod
>
>
> On Tue, 12 Dec 2023 at 19:22, Ilari Liusvaara 
> wrote:
>
> On Fri, Dec 08, 2023 at 05:47:01PM +, Salz, Rich wrote:
> >
> > Good point.  https://github.com/richsalz/tls12-frozen/pull/12 has the
> > change.  I’ll wait until/if this is adopted by the WG to merge it.
>
> Reading through the document, I noticed the following:
>
> "To securely deploy TLS 1.2, either renegotiation must be disabled
> entirely, or this extension must be present." (where this extension
> means renegotiation_info)
>
>
> Entirely disabling renegotiation is not sufficient to fix the
> renegotiation issue in TLS 1.2. For fixing the issue, renegotiation_info
> MUST be required both ways.
>
> And then there is the other part to the triple handshake attack where
> using TLS exporters for authentication without extended_master_secret
> extension is insecure, even if renegotiation is not supported at all
> by either side and both sides implement renegotiation_info.
>
> And then there is more dangerously flawed stuff, e.g., session tickets
> (technically an extension).
>
>
>
>
> -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
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Peter Gutmann]

Arnaud Taddei writes:

>This is why I asked the question whether there would be volunteers to design
>a ‘survey’ approach.
>
>This could bring data points from the broader community that could help guide
>this particular area of the work.

I don't think the problem is volunteers, it's getting anyone to go on record,
or even off-the-record, about it.  For (say) SCADA stuff you're talking to
embedded systems and networking engineers deep down in the internals of large
corporations/organisations who can't speak publicly about anything, and I
doubt anyone higher up who can go on the record is going to bother making a
statement about their TLS migration policy.  Even getting a boring and very
sanitised tech report on something published can take so much paperwork that
it's sometimes easier to drop co-authors than to try and get approval to have
their names added.  This is why the stuff I post here is often anecdotal and
quite redacted, or done off-list, because it's too much of a headache to go
through the paperwork to say anything publicly.

Having said that, if someone can figure out a way to get the data out, it'd be
great to have it available.

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Peter Gutmann]

Watson Ladd  writes:

>Why would deploying that change to TLS 1.2 be easier than deploying TLS 1.3?

One is making a (presumably) small tweak to an existing deployed protocol, the
other is deploying an entirely new protocol.  They're totally different
things.

(Not to mention additional issues like some devices not having the headroom to
run two different protocol stacks side by side and other odds and ends, but
those are minor nits).

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[William Stratton Apsokardu]

Facebook Facebook
FacebookFacebook
Get Outlook for iOS<https://aka.ms/o0ukef>

From: TLS  on behalf of Nimrod Aviram 

Sent: Wednesday, December 13, 2023 9:49:55 AM
To: Ilari Liusvaara 
Cc: TLS@ietf.org 
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

Hi Ilari, thanks for the clarification!

I attempted to correct the text.
Would you be willing to review the change? It's here:
https://github.com/richsalz/tls12-frozen/commit/a1ce7ede97897e291af44f0c2f4fc225a2ca4447

thanks,
Nimrod


On Tue, 12 Dec 2023 at 19:22, Ilari Liusvaara 
mailto:ilariliusva...@welho.com>> wrote:
On Fri, Dec 08, 2023 at 05:47:01PM +, Salz, Rich wrote:
>
> Good point.  https://github.com/richsalz/tls12-frozen/pull/12 has the
> change.  I’ll wait until/if this is adopted by the WG to merge it.

Reading through the document, I noticed the following:

"To securely deploy TLS 1.2, either renegotiation must be disabled
entirely, or this extension must be present." (where this extension
means renegotiation_info)


Entirely disabling renegotiation is not sufficient to fix the
renegotiation issue in TLS 1.2. For fixing the issue, renegotiation_info
MUST be required both ways.

And then there is the other part to the triple handshake attack where
using TLS exporters for authentication without extended_master_secret
extension is insecure, even if renegotiation is not supported at all
by either side and both sides implement renegotiation_info.

And then there is more dangerously flawed stuff, e.g., session tickets
(technically an extension).




-Ilari

___
TLS mailing list
TLS@ietf.org<mailto: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] Adoption call for 'TLS 1.2 Feature Freeze'

[Nimrod Aviram]

Hi Ilari, thanks for the clarification!

I attempted to correct the text.
Would you be willing to review the change? It's here:
https://github.com/richsalz/tls12-frozen/commit/a1ce7ede97897e291af44f0c2f4fc225a2ca4447

thanks,
Nimrod


On Tue, 12 Dec 2023 at 19:22, Ilari Liusvaara 
wrote:

> On Fri, Dec 08, 2023 at 05:47:01PM +, Salz, Rich wrote:
> >
> > Good point.  https://github.com/richsalz/tls12-frozen/pull/12 has the
> > change.  I’ll wait until/if this is adopted by the WG to merge it.
>
> Reading through the document, I noticed the following:
>
> "To securely deploy TLS 1.2, either renegotiation must be disabled
> entirely, or this extension must be present." (where this extension
> means renegotiation_info)
>
>
> Entirely disabling renegotiation is not sufficient to fix the
> renegotiation issue in TLS 1.2. For fixing the issue, renegotiation_info
> MUST be required both ways.
>
> And then there is the other part to the triple handshake attack where
> using TLS exporters for authentication without extended_master_secret
> extension is insecure, even if renegotiation is not supported at all
> by either side and both sides implement renegotiation_info.
>
> And then there is more dangerously flawed stuff, e.g., session tickets
> (technically an extension).
>
>
>
>
> -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] Adoption call for 'TLS 1.2 Feature Freeze'

[Arnaud Taddei]

Whilst I don’t know Peter, my intervention in San Francisco on this topic was 
on the same line.

Am working with the CISO teams of organizations that have to keep their 
infrastructure for 50 to 100 years long plans (nuclear power stations, 
hydraulic infrastructures, etc.).

And among organizations I engage with, several DO have active plans to migrate 
out from TLS1.2 … but this is very hard!

I learnt the hard way that migration projects are always the hardest possible 
projects vs say build something from scratch.

Unfortunately there is one large part of the community which is not at the IETF 
ever or anymore to voice those concerns.

Now, on the other hand, I do support the ‘active signals’ approach proposed by 
Rich and the adoption of this text exactly for the reasons expressed by Rich.

My only ‘amendment’ is how we could stay connected with the community which is 
still on TLS1.2 and what is the magnitude of their issues, why, etc.

This is why I asked the question whether there would be volunteers to design a 
‘survey’ approach.

This could bring data points from the broader community that could help guide 
this particular area of the work.

If there would be some appetite, designing such a survey is not an easy task 
but should we agree, I would certainly be happy to gain the support from my 
organization to deploy this survey and get feedback from as many organizations 
as possible.

My 0.02 CHF

From: TLS  on behalf of Salz, Rich 

Date: Tuesday, 12 December 2023 at 18:53
To: Rob Sayre , Peter Gutmann 
Cc: TLS@ietf.org 
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
Peter knows more about long-term embedded systems that use TLS than anyone else 
on this list.  I trust him. Don’t think of things connected to the public 
Internet, but rather things like client-auth missle launching systems, seismic 
(nuclear) monitoring equipment, and the like.  Stuff that you cannot pick up 
anywhere retail off-the-shelf, but is rather purpose-built.

Having said that, I don’t want this draft to make his job harder; I’d rather my 
electric grid didn’t break :) But given that, and since he doesn’t have a 
specific concern in-hand right now, and that I think it is important and useful 
to send a clear signal to the global community, I’d still like to see the draft 
adopted and eventually published.

It sends an active signal about new features, as opposed to a passive signal of 
just not accepting work. In my experience in security, active signals are 
better than passive ones.


-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Watson Ladd]

On Tue, Dec 12, 2023 at 1:23 AM Peter Gutmann  wrote:
>
> Viktor Dukhovni  writes:
>
> >Peter, is there anything beyond TLS-TLS that you're looking to see work on?
> >Is the issue foreclosing on opportunities to do anticipated necessary work,
> >or is it mostly that the statement that the work can't happen causing
> >disruption with audits and other bureaucratic issues?
>
> I can't foresee anything, but I also can't predict what the future will bring.
> It's more a case of some currently unknown thing cropping up and an RFC saying
> you can't make any changes preventing anything being done, at least in a
> published-standard manner.

Why would deploying that change to TLS 1.2 be easier than deploying TLS 1.3?

>
> If it really is necessary to publish an RFC like this then perhaps text along
> the lines of "you can't add major new features but performing maintenance is
> OK" would work, although overall I still can't see why such an RFC is
> necessary in the first place.

The point is (IMHO) twofold: first it's to explain to other WGs and
SDOs that they should use TLS 1.3 and not demand new features in TLS
1.2 instead of coming to us each time to tell them, and secondly it's
to avoid rehashing this every time such a proposal comes up.

>
> Peter.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
Astra mortemque praestare gradatim

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Salz, Rich]

Peter knows more about long-term embedded systems that use TLS than anyone else 
on this list.  I trust him. Don’t think of things connected to the public 
Internet, but rather things like client-auth missle launching systems, seismic 
(nuclear) monitoring equipment, and the like.  Stuff that you cannot pick up 
anywhere retail off-the-shelf, but is rather purpose-built.

Having said that, I don’t want this draft to make his job harder; I’d rather my 
electric grid didn’t break :) But given that, and since he doesn’t have a 
specific concern in-hand right now, and that I think it is important and useful 
to send a clear signal to the global community, I’d still like to see the draft 
adopted and eventually published.

It sends an active signal about new features, as opposed to a passive signal of 
just not accepting work. In my experience in security, active signals are 
better than passive ones.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Rob Sayre]

On Tue, Dec 12, 2023 at 1:09 AM Peter Gutmann 
wrote:

> are
> you saying you don't believe that there are systems out there deployed and
> used with multi-decade life cycles?


I believe that--but these are so old that the other parts are starting to
become a problem. In my case, the ethernet stack is a bit obsolete, and
needs special treatment.

That said, the draft doesn't deny the existence of TLS 1.2 on old hardware.
It says:

  "Both versions have several extension points, so items like new
   cryptographic algorithms, new supported groups (formerly "named
   curves"), etc., can be added without defining a new protocol.  This
   document specifies that outside of urgent security fixes, no new
   features will be approved for TLS 1.2."

So, this document makes it clear that the 15yr-old TLS 1.2 RFC is not going
to be getting new features. This is already true, really. For example, ECH
requires TLS 1.3+, and there's a lot of QUIC traffic out there (RFC 9001:
"Clients MUST NOT offer TLS versions older than 1.3.").

I can't see why anyone aiming for multi-decade deployments would start with
TLS 1.2 today. I have been dismayed to see WGs like UTA and NETCONF list
TLS 1.2 as a MUST in 2023. I can understand that people might /choose/ to
support it, where there's a bunch of older hardware around. But as a
conformance requirement, or as a target for feature work, it doesn't make
sense to me.

It's starting to resemble Homer's sandwich:


The draft is a good idea, because it makes what is already happening clear.
But it seems like not every WG is getting the memo (even if they don't like
it). The conversation basically goes "why is TLS 1.2 a MUST?" and the
answer is "allowing 1.3-only implementations would be controversial"
without really explaining what that controversy might be.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Ilari Liusvaara]

On Fri, Dec 08, 2023 at 05:47:01PM +, Salz, Rich wrote:
> 
> Good point.  https://github.com/richsalz/tls12-frozen/pull/12 has the
> change.  I’ll wait until/if this is adopted by the WG to merge it.

Reading through the document, I noticed the following:

"To securely deploy TLS 1.2, either renegotiation must be disabled
entirely, or this extension must be present." (where this extension
means renegotiation_info)


Entirely disabling renegotiation is not sufficient to fix the
renegotiation issue in TLS 1.2. For fixing the issue, renegotiation_info
MUST be required both ways.

And then there is the other part to the triple handshake attack where
using TLS exporters for authentication without extended_master_secret
extension is insecure, even if renegotiation is not supported at all
by either side and both sides implement renegotiation_info.

And then there is more dangerously flawed stuff, e.g., session tickets
(technically an extension).




-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Achim Kraus]

Hi Peter,

with or without "freeze", I guess it will be not too easy to get enough
interest for required discussions and reviews to change or fix TLS 1.2.
On the other side, if there is enough interest for a special future 1.2
topic, I also don't get it, why that should be blocked with an "feature
freeze". For me it looks quite common, that only those who are
interested are participating in discussions. Those who are not
interested don't need to spend time. At least, I don't see, that someone
has to spend in the future more time in TLS 1.2 than in this discussion
about to "freeze" it.

(Yes, I read that "once" and then "never again". We will see, if that
works.)

best regards
Achim


Am 12.12.23 um 10:09 schrieb Peter Gutmann:

Rob Sayre  writes:


On Mon, Dec 11, 2023 at 5:30 PM Peter Gutmann  wrote:

Absolutely clear.  I work with stuff with 20-30 year deployment and life
cycles.  I'm fairly certain TLS 1.2 will still be around when the WebTLS
world is debating the merits of TLS 1.64 vs. TLS 1.65.


I have to say, I am skeptical of this claim.


Which one, that there is equipment out there with 20-30 year life cycles or
that the WebTLS folks will be arguing over TLS 1.64 in the future?  If the
latter then it may just be TLS 1.59 at that point, as I said I can't see the
future.  If the former then I don't really know how to respond to that, are
you saying you don't believe that there are systems out there deployed and
used with multi-decade life cycles?

Peter.
___
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] Adoption call for 'TLS 1.2 Feature Freeze'

[Peter Gutmann]

Loganaden Velvindron  writes:

>I'm curious. Are those embedded devices or IoT type of appliances where the
>firmware has a TLS library that will never be updated ?

Typically, yes.  Many devices don't support remote firmware update, or need
physical access to do it so it's never done, or will be decertified if you
change the firmware so it's also never done.

Some of these things also have 5-10 year development cycles, so there's an
emphasis on getting it right the first time (as well as ensuring things like
guaranteed supply of hardware for long periods, for example most embedded CPUs
have 15-year supply longevity guarantees for this purpose, so if you were to
start a new design today and have it done by 2028 you'd know the same chip
would still be manufactured until 2038, at which point you buy up all the
remaining production and stockpile it).  Devices may gradually get updated
over time as new units ship with newer firmware, but they're typically run
alongside existing devices rather than replacing them.

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Peter Gutmann]

Viktor Dukhovni  writes:

>Peter, is there anything beyond TLS-TLS that you're looking to see work on?
>Is the issue foreclosing on opportunities to do anticipated necessary work,
>or is it mostly that the statement that the work can't happen causing
>disruption with audits and other bureaucratic issues?

I can't foresee anything, but I also can't predict what the future will bring.
It's more a case of some currently unknown thing cropping up and an RFC saying
you can't make any changes preventing anything being done, at least in a
published-standard manner.

If it really is necessary to publish an RFC like this then perhaps text along
the lines of "you can't add major new features but performing maintenance is
OK" would work, although overall I still can't see why such an RFC is
necessary in the first place.

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[hannes . tschofenig=40gmx . net]

>From my experience, it is possible to update the firmware on many modern 
>constrained IoT devices, including the TLS / DTLS stack, today. Of course, 
>there are a lot of devices out there where updating the firmware involves 
>physical access by some technician.

However, there are a few other challenges. 

First, such a change must be carefully planned since the space on these devices 
is quite limited.

Second, IoT devices often follow "system" standards and for interoperability 
purposes you cannot just replace one version of the security protocol with 
another one. In some IoT standards, you can "easily" switch from one TLS 
version to the next without impacting the interoperability of the entire 
system. This is not necessarily the case with all IoT specifications. There are 
often other subtle changes that have an impact on the transition. For example, 
if you have an IoT deployment that uses EAP-TLS based on RFC 5216 and you 
switch to RFC 9190 then you are suddenly facing the requirement to use OCSP 
stapling in TLS, if you strictly follow RFC 9190. In general, you have to look 
at the whole system rather than just at a single IoT device alone. There may 
also be certification processes to consider. 

Then, there is the incentive issue. Just because there is a new version of TLS 
available does not immediately trigger companies to update their devices, 
particularly when there is not even a security problem with 1.2 (at least if 
you follow the recommendations from the UTA group).

Finally, implementations with the desired feature set also have to be 
available. Depending on the stack you are using, this might be the case, but it 
is not guaranteed. Implementing embedded security protocols takes more time 
than writing a Javascript app...

Ciao
Hannes
 
-Original Message-
From: TLS  On Behalf Of Loganaden Velvindron
Sent: Dienstag, 12. Dezember 2023 06:17
To: Peter Gutmann 
Cc: tls@ietf.org
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

Peter,

I'm curious. Are those embedded devices or IoT type of appliances where the 
firmware has a TLS library that will never be updated ?


On Tue, 12 Dec 2023 at 05:30, Peter Gutmann  wrote:
>
> Rob Sayre  writes:
>
> >>Given that TLS 1.2 will be around for quite some time
> >Not clear.
>
> Absolutely clear.  I work with stuff with 20-30 year deployment and 
> life cycles.  I'm fairly certain TLS 1.2 will still be around when the 
> WebTLS world is debating the merits of TLS 1.64 vs. TLS 1.65.
>
> (This is also why the TLS-LTS draft was created, BTW).
>
> Peter.
>
>
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Peter Gutmann]

Off-list: Funny that you should mention nuclear power plants, at least one of 
the systems I'm thinking of is used in nuclear power control.  Those things are 
remarkably resilient, including in at least one case having the facility 
overrun by an invading army.  They looted all the standard PCs but didn't know 
what the controllers were, once the facility was liberated they reconnected the 
controllers and they resumed operation as if nothing had happened (they have 
internal power sources so kept running despite external power being cut).  
They're between 20 and 25 years old, and I haven't seen any plans to retire 
them.

Peter.




From: TLS  on behalf of Viktor Dukhovni 

Sent: Tuesday, 12 December 2023 17:49
To: TLS@ietf.org
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

On Mon, Dec 11, 2023 at 07:51:13PM -0800, Rob Sayre wrote:

> > Absolutely clear.  I work with stuff with 20-30 year deployment and
> > life cycles.  I'm fairly certain TLS 1.2 will still be around when
> > the WebTLS world is debating the merits of TLS 1.64 vs. TLS 1.65.
>
> I have to say, I am skeptical of this claim. The reason being that you
> don't really want 20 year old computers connected directly to local
> ethernet without a bridge.

Did Peter say anything about (general purpose) computers or connections
to the "local ethernet" (or Internet)?  Suppose you have a control
system for a ship, an factory floor, or a nuclear power plant.

How often would one want to perform major software updates that
substantially change aspects of the system design?  What is the expected
lifetime of such systems?

Since Peter has been addressing market needs in that space for some
decades, I'd be inclined to take him at his word...

Again, it may well be that he does not have a compelling case for
ongoing TLS working-group processes to enhance TLS 1.2, or he may yet.

Peter, is there anything beyond TLS-TLS that you're looking to see work
on?  Is the issue foreclosing on opportunities to do anticipated
necessary work, or is it mostly that the statement that the work can't
happen causing disruption with audits and other bureaucratic issues?

--
Viktor.

___
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] Adoption call for 'TLS 1.2 Feature Freeze'

[Peter Gutmann]

Rob Sayre  writes:

>>On Mon, Dec 11, 2023 at 5:30 PM Peter Gutmann  
>>wrote:
>>
>>Absolutely clear.  I work with stuff with 20-30 year deployment and life
>>cycles.  I'm fairly certain TLS 1.2 will still be around when the WebTLS
>>world is debating the merits of TLS 1.64 vs. TLS 1.65.
>
>I have to say, I am skeptical of this claim.

Which one, that there is equipment out there with 20-30 year life cycles or
that the WebTLS folks will be arguing over TLS 1.64 in the future?  If the
latter then it may just be TLS 1.59 at that point, as I said I can't see the
future.  If the former then I don't really know how to respond to that, are
you saying you don't believe that there are systems out there deployed and
used with multi-decade life cycles?

Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Loganaden Velvindron]

Peter,

I'm curious. Are those embedded devices or IoT type of appliances
where the firmware has a TLS
library that will never be updated ?


On Tue, 12 Dec 2023 at 05:30, Peter Gutmann  wrote:
>
> Rob Sayre  writes:
>
> >>Given that TLS 1.2 will be around for quite some time
> >Not clear.
>
> Absolutely clear.  I work with stuff with 20-30 year deployment and life
> cycles.  I'm fairly certain TLS 1.2 will still be around when the WebTLS world
> is debating the merits of TLS 1.64 vs. TLS 1.65.
>
> (This is also why the TLS-LTS draft was created, BTW).
>
> Peter.
>
>
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Viktor Dukhovni]

On Mon, Dec 11, 2023 at 07:51:13PM -0800, Rob Sayre wrote:

> > Absolutely clear.  I work with stuff with 20-30 year deployment and
> > life cycles.  I'm fairly certain TLS 1.2 will still be around when
> > the WebTLS world is debating the merits of TLS 1.64 vs. TLS 1.65.
> 
> I have to say, I am skeptical of this claim. The reason being that you
> don't really want 20 year old computers connected directly to local
> ethernet without a bridge.

Did Peter say anything about (general purpose) computers or connections
to the "local ethernet" (or Internet)?  Suppose you have a control
system for a ship, an factory floor, or a nuclear power plant.

How often would one want to perform major software updates that
substantially change aspects of the system design?  What is the expected
lifetime of such systems?

Since Peter has been addressing market needs in that space for some
decades, I'd be inclined to take him at his word...

Again, it may well be that he does not have a compelling case for
ongoing TLS working-group processes to enhance TLS 1.2, or he may yet.

Peter, is there anything beyond TLS-TLS that you're looking to see work
on?  Is the issue foreclosing on opportunities to do anticipated
necessary work, or is it mostly that the statement that the work can't
happen causing disruption with audits and other bureaucratic issues?

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Peter Gutmann]

Rob Sayre  writes:

>>Given that TLS 1.2 will be around for quite some time
>Not clear.

Absolutely clear.  I work with stuff with 20-30 year deployment and life
cycles.  I'm fairly certain TLS 1.2 will still be around when the WebTLS world
is debating the merits of TLS 1.64 vs. TLS 1.65.

(This is also why the TLS-LTS draft was created, BTW).

Peter.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Peter Gutmann]

Watson Ladd  writes:

>How does a feature freeze make it impossible to keep supporting TLS 1.2 as
>is?

Because if there's some tweak required for some reason (I don't know what that
could be since I can't predict the future) the draft seems to prohibit it.

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Watson Ladd]

On Mon, Dec 11, 2023 at 5:15 PM Peter Gutmann  wrote:
>
> In all the rush to jump on the bandwagon, no-one has yet answered the question
> I posed earlier: For anyone who's already moved to TLS 1.3 the draft is
> irrelevant, and for people who have to keep supporting TLS 1.2 gear more or
> less indefinitely it makes their job hard if not impossible.

How does a feature freeze make it impossible to keep supporting TLS 1.2 as is?

> So what's the
> point of this draft?  For TLS 1.3 it's just workgroup posturing which I don't
> have a problem with (I was on the PKIX WG for years, that was practically in
> their charter), but for ongoing TLS 1.2 use it's going to pointlessly make
> life difficult for anyone working in that area.
>
> Why is this draft even a thing?
>
> Peter.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
Astra mortemque praestare gradatim

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Peter Gutmann]

In all the rush to jump on the bandwagon, no-one has yet answered the question
I posed earlier: For anyone who's already moved to TLS 1.3 the draft is
irrelevant, and for people who have to keep supporting TLS 1.2 gear more or
less indefinitely it makes their job hard if not impossible.  So what's the
point of this draft?  For TLS 1.3 it's just workgroup posturing which I don't
have a problem with (I was on the PKIX WG for years, that was practically in
their charter), but for ongoing TLS 1.2 use it's going to pointlessly make
life difficult for anyone working in that area.

Why is this draft even a thing?

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Viktor Dukhovni]

On Mon, Dec 11, 2023 at 06:38:05PM -0500, David Benjamin wrote:

> Protocol changes generally require both client and server changes to take
> effect. Pre-existing deployments, by simply pre-existing, will not have
> those changes. If we add, say, post-quantum options for TLS 1.2, it will
> benefit zero existing TLS 1.2 deployments. If we add post-quantum options
> for TLS 1.3, it will benefit zero existing TLS 1.3 deployments. That's not
> why we make these changes. We make them to benefit *future* TLS
> deployments, e.g. when server operators update their software. Although it
> can be a slow progress, pre-existing deployments gradually cycle into
> updated deployments.

FWIW, I had already considered this, and in fact essentially agree with
this take on the tradeoffs.  My point is mainly that there is legitimate
room for some diversity of opinion.

As you noted in your response, the PKCS1 barrier to TLS 1.3 adoption
that might be holding back some operators will be addressed.  Another,
that likely won't is that negotiation of "psk_ke" is particularly
brittle in TLS 1.3, and in constrained environments DH on every
resumption could be problematic.

My personal list of pain points is short, others can probably think of a
few more.  I actually don't object to the draft.  Rather, perhaps
"over", reacting to Rob's apparent negative reaction to posing the
question of whether the draft was *necessary*.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[David Benjamin]

I don't think that quite captures the tradeoffs. Sure, TLS 1.2 will be
around for quite some time, but that *does not mean it is worth adding new
features to TLS 1.2*. Those two statements are not directly related.

Protocol changes generally require both client and server changes to take
effect. Pre-existing deployments, by simply pre-existing, will not have
those changes. If we add, say, post-quantum options for TLS 1.2, it will
benefit zero existing TLS 1.2 deployments. If we add post-quantum options
for TLS 1.3, it will benefit zero existing TLS 1.3 deployments. That's not
why we make these changes. We make them to benefit *future* TLS
deployments, e.g. when server operators update their software. Although it
can be a slow progress, pre-existing deployments gradually cycle into
updated deployments.

So when we decide whether to make a change to TLS 1.2 or TLS 1.3, the
pre-existing deployments of both protocols are irrelevant. What matters is
what will be used in new TLS software. At this point, now that TLS 1.3 is
well-established, we should broadly expect new TLS software to be
TLS-1.3-capable. Thus is it not worth our time to backport such changes to
TLS 1.2. When I say "our", I don't mean just this working group, but also
TLS implementers, application software that configures TLS implementations,
and server operators who must somehow navigate the sea of options that
comes from everyone else's indecision. Together, those costs are
significant.

More than that, we (the WG) should communicate this expectation. We did it
once by publishing RFC 8446 and obsoleting RFC 5246. hence this document.
But communication is hard, and now that the expectation is stronger, we
should repeat it more strongly. There will always be stragglers and
misunderstandings. Perhaps some more obscure TLS implementation has yet to
implement TLS 1.3. (Or DTLS 1.3.) Perhaps some application has a hardcoded
TLS 1.2 setting that needs to be updated. Perhaps some config files are
stale.

Publishing this document helps clear up what was already the WG's
expectation. If it reminds a chunk of those folks to move to TLS 1.3, it
will have been worthwhile. That is also why mentioning PQC is valuable, as
it is the extension that is most likely to be on server operators' minds.

Finally, communicating this is useful to us. Perhaps some new deployments
are TLS 1.2 not out of inertia, but because something in TLS 1.3
inadvertently made migration difficult for those folks. In that case, us
publishing this document helps invite such feedback. For example,
draft-ietf-tls-tls13-pkcs1 addresses a migration challenge. (That specific
example long predates this and, judging by the list discussion in 2019, it
was perhaps a little ahead of its time, but we all got there eventually.
:-D)

This has nothing to do with raising the floor. This is about not bothering
to start a new, shorter tower on the side while we raise the main ceiling.

On Mon, Dec 11, 2023, 16:58 Viktor Dukhovni  wrote:

> On Mon, Dec 11, 2023 at 12:32:36PM -0800, Rob Sayre wrote:
>
> > PS - I have to say, not in this message, but sometimes it seems like the
> > goal of TLS 1.2 advocates is weaker encryption. So, for them, the flaws
> in
> > TLS 1.2 that the draft describes are desirable. If that's the case,
> > participants are not working toward the same goal. Writing down the
> > consensus seems worth it.
>
> For what it is worth, my agenda/perspective has never been to weaken
> encryption.  Rather, it has always been about making usable encryption
> ubiquitous.  While we continue work on raising the ceiling, one can be
> legitimately weary of raising the floor so high that encryption is
> unusable, and communication happens in the clear instead.
>
> Given that TLS 1.2 will be around for quite some time, it is not obvious
> that a feature freeze will in practice improve security.  It is good
> that there's ongoing effort to make TLS 1.3 better, and I accept that it
> may well not be possible to deliver on required TLS 1.3 work and to also
> make some occasional modest improvements to TLS 1.2, but if the goal is
> to deliver secure products to users, a realist might accept that TLS 1.2
> is likely to continue to be used for some time, and that those users
> could be better served if some improvements continued to take place.
>
> The contrarian possition of course assumes that such improvements
> wouldn't be a significant drain on scarce resources.  That assumption is
> a matter for debate, and the "right" trade-offs are not completely
> obvious.  Some difference of perspectives can be expected.
>
> Whatever else we do, we should not default to questioning the motives of
> others who would make somewhat different tradeoffs.  Worry more when
> everyone is in violent agreement, perhaps something is then being
> missed.
>
> --
> Viktor.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Viktor Dukhovni]

On Mon, Dec 11, 2023 at 02:40:41PM -0800, Rob Sayre wrote:

> > Given that TLS 1.2 will be around for quite some time
> 
> Not clear.

As a data point, I've had no luck so far with encouraging the email
operators of domain-registry.bg to upgrade their primary MX from TLS 1.0
to at least TLS 1.2. :-(

> I don't think anyone did that (including me). The question is whether the
> IETF should state that continuing work on TLS 1.2 is not worth doing.

Indeed that's the question, but there's a spectrum of choices.  One
choice is to preclude such work now.  Another is to swiftly decline
non-compelling proposals as they come up.

If there is indeed a sufficient stream of new distracting proposed TLS
1.2 tweaks then perhaps closing the gate is well motivated.  If the
volume of proposals is sufficiently low, there's no need to solve
non-problems.  Somewhere in between it can be difficult to know which is
the right choice, but we can but do our best.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Rob Sayre]

Viktor Dukhovni  wrote:
> For what it is worth, my agenda/perspective has never been to weaken
encryption.

Right, I wrote that your message was not something that advocated weakened
encryption.

> Given that TLS 1.2 will be around for quite some time

Not clear.

> Whatever else we do, we should not default to questioning the motives of
others

I don't think anyone did that (including me). The question is whether the
IETF should state that continuing work on TLS 1.2 is not worth doing.

There are drafts that champion TLS 1.2 flaws in the name of
"observability". So, it's easy to understand that not everyone agrees here.
That's why I think it's best to document the IETF consensus.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Viktor Dukhovni]

On Mon, Dec 11, 2023 at 12:32:36PM -0800, Rob Sayre wrote:

> PS - I have to say, not in this message, but sometimes it seems like the
> goal of TLS 1.2 advocates is weaker encryption. So, for them, the flaws in
> TLS 1.2 that the draft describes are desirable. If that's the case,
> participants are not working toward the same goal. Writing down the
> consensus seems worth it.

For what it is worth, my agenda/perspective has never been to weaken
encryption.  Rather, it has always been about making usable encryption
ubiquitous.  While we continue work on raising the ceiling, one can be
legitimately weary of raising the floor so high that encryption is
unusable, and communication happens in the clear instead.

Given that TLS 1.2 will be around for quite some time, it is not obvious
that a feature freeze will in practice improve security.  It is good
that there's ongoing effort to make TLS 1.3 better, and I accept that it
may well not be possible to deliver on required TLS 1.3 work and to also
make some occasional modest improvements to TLS 1.2, but if the goal is
to deliver secure products to users, a realist might accept that TLS 1.2
is likely to continue to be used for some time, and that those users
could be better served if some improvements continued to take place.

The contrarian possition of course assumes that such improvements
wouldn't be a significant drain on scarce resources.  That assumption is
a matter for debate, and the "right" trade-offs are not completely
obvious.  Some difference of perspectives can be expected.

Whatever else we do, we should not default to questioning the motives of
others who would make somewhat different tradeoffs.  Worry more when
everyone is in violent agreement, perhaps something is then being
missed.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Rob Sayre]

Viktor Dukhovni  wrote:
> I do however wonder why this requires a draft formalising the stance?
> [...]
> Is the draft actually necessary?

It is a good way to avoid continually discussing the matter. So, yes, it
will save time: by documenting IETF consensus.

thanks,
Rob

PS - I have to say, not in this message, but sometimes it seems like the
goal of TLS 1.2 advocates is weaker encryption. So, for them, the flaws in
TLS 1.2 that the draft describes are desirable. If that's the case,
participants are not working toward the same goal. Writing down the
consensus seems worth it.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Viktor Dukhovni]

On Wed, Dec 06, 2023 at 12:33:52AM -0500, Deirdre Connolly wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call
> is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.

I take no issue with the WG declining to do further non-emergency work
on TLS 1.2, if that promotes best use of scarce WG cycles.

I do however wonder why this requires a draft formalising the stance?
The simplest way to not do non-emergency work on TLS 1.2 seems to me to
not do non-emergency work on TLS 1.2.  Is the draft actually necessary?

Would not working on the draft save even more cycles?

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Arnaud Taddei]

Ditto +1 to Rich

From: TLS  on behalf of Bas Westerbaan 

Date: Monday, 11 December 2023 at 18:21
To: Salz, Rich 
Cc: Hannes Tschofenig , 
TLS@ietf.org 
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
The draft itself is an exercise in clear communication, and mentioning PQC 
explicitly fits with that.  Thus I agree with Rich to keep it.

Best,

 Bas

On Mon, Dec 11, 2023 at 6:18 PM Salz, Rich 
mailto:rs...@akamai.com>> wrote:
· that is implied by a "feature freeze". No reason to highlight PQC 
(even though it is a hype topic right now).

Yes, to both of these.  But I still think it should be explicitly called out.  
If the WG thinks otherwise, then fine, the document is that much shorter :)

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Bas Westerbaan]

The draft itself is an exercise in clear communication, and mentioning PQC
explicitly fits with that.  Thus I agree with Rich to keep it.

Best,

 Bas

On Mon, Dec 11, 2023 at 6:18 PM Salz, Rich  wrote:

>
>- that is implied by a "feature freeze". No reason to highlight PQC
>(even though it is a hype topic right now).
>
> Yes, to both of these.  But I still think it should be explicitly called
> out.  If the WG thinks otherwise, then fine, the document is that much
> shorter :)
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Salz, Rich]

  *   that is implied by a "feature freeze". No reason to highlight PQC (even 
though it is a hype topic right now).

Yes, to both of these.  But I still think it should be explicitly called out.  
If the WG thinks otherwise, then fine, the document is that much shorter :)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Watson Ladd]

On Tue, Dec 5, 2023, 9:34 PM Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>

I support adoption and can review.

>
> Thanks,
> Deirdre, Joe, and Sean
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Hannes Tschofenig]

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:


  * I consider Section 3 "Implications for post-quantum cryptography"
misplaced. I suggest to delete the section
  * 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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Salz, Rich]

  *   I consider Section 3 "Implications for post-quantum cryptography" 
misplaced. I suggest to delete the section
  *   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

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Dennis Jackson]

I support adoption, and am happy to review.

Best,
Dennis

On 06/12/2023 12:50, Salz, Rich wrote:


At the TLS meeting at IETF 118 there was significant support for the 
draft 'TLS 1.2 is in Feature Freeze' 
(https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/ 
) 
 This call is to confirm this on the list.  Please indicate if you 
support the adoption of this draft and are willing to review and 
contribute text. If you do not support adoption of this draft please 
indicate why.  This call will close on December 20, 2023.


As the co-author, I support this and am willing to continue working on 
it as needed.



___
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] Adoption call for 'TLS 1.2 Feature Freeze'

[Hannes Tschofenig]

I consider Section 3 "Implications for post-quantum cryptography"
misplaced. I suggest to delete the section


The motivation for the draft is unrelated to developments with PQC.


Ciao

Hannes



Am 11.12.2023 um 11:59 schrieb Bas Westerbaan:

I support adoption, and am happy to review.

Best,

 Bas

On Wed, Dec 6, 2023 at 6:34 AM Deirdre Connolly
 wrote:

At the TLS meeting at IETF 118 there was significant support for
the draft 'TLS 1.2 is in Feature Freeze'
(https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)
 This call is to confirm this on the list.  Please indicate if you
support the adoption of this draft and are willing to review and
contribute text. If you do not support adoption of this draft
please indicate why.  This call will close on December 20, 2023.

Thanks,
Deirdre, Joe, and Sean
___
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] Adoption call for 'TLS 1.2 Feature Freeze'

[Bas Westerbaan]

I support adoption, and am happy to review.

Best,

 Bas

On Wed, Dec 6, 2023 at 6:34 AM Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, Joe, and Sean
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Salz, Rich]

  *   NEW2: ” Cryptographically relevant quantum computers, once available, 
will have a huge impact on RSA, FFDH, ECC which are currently used in TLS.”

Good point.  https://github.com/richsalz/tls12-frozen/pull/12 has the change.  
I’ll wait until/if this is adopted by the WG to merge it.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[John Mattsson]

Hi,

A comment on the draft that should be updated in the next version:

OLD: ”Quantum computers, once available, will have a huge impact on TLS.”

A lot of people already have small, error prone, and currently quite useless 
quantum computers. I suggest changing to Cryptographically Relevant Quantum 
Computers (CRQC). It is still unclear if and when CRQCs will be constructed. 
The goal is that TLS will change to quantum-resistant algorithms and that CRQC 
when/if they are constructed will not have a huge impact on TLS.

I suggest that you correct this sentence to say one of:
NEW1: ”The threat of Cryptographically relevant quantum computers, once 
available, will have a huge impact on TLS.”

NEW2: ” Cryptographically relevant quantum computers, once available, will have 
a huge impact on RSA, FFDH, ECC which are currently used in TLS.”

Cheers,
John Preuß Mattsson

From: TLS  on behalf of Chris Barber 

Date: Thursday, 7 December 2023 at 21:41
To: TLS@ietf.org 
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
I've reviewed the document and endorse its adoption.

It's not worth spending more time on TLS < 1.3, and the draft can help to 
improve TLS 1.3 adoption.

It isn't worthwhile to invest additional time in TLS versions earlier than 1.3, 
and the draft can contribute to enhancing the adoption of TLS 1.3.

On Wed, Dec 6, 2023 at 6:34 AM Deirdre Connolly 
mailto:durumcrustu...@gmail.com>> wrote:
At the TLS meeting at IETF 118 there was significant support for the draft 'TLS 
1.2 is in Feature Freeze' 
(https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call is 
to confirm this on the list.  Please indicate if you support the adoption of 
this draft and are willing to review and contribute text. If you do not support 
adoption of this draft please indicate why.  This call will close on December 
20, 2023.

Thanks,
Deirdre, Joe, and Sean
___
TLS mailing list
TLS@ietf.org<mailto: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] Adoption call for 'TLS 1.2 Feature Freeze'

[Chris Barber]

I've reviewed the document and endorse its adoption.

It's not worth spending more time on TLS < 1.3, and the draft can help to
improve TLS 1.3 adoption.

It isn't worthwhile to invest additional time in TLS versions earlier than
1.3, and the draft can contribute to enhancing the adoption of TLS 1.3.

On Wed, Dec 6, 2023 at 6:34 AM Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, Joe, and Sean
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Loganaden Velvindron]

I support adoption.

On Wed, Dec 6, 2023, 09:35 Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, Joe, and Sean
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Marten Seemann]

I support adoption.

On Thu, 7 Dec 2023 at 05:55, David Schinazi 
wrote:

> I support adoption.
> David
>
> On Wed, Dec 6, 2023 at 4:16 PM Rob Sayre  wrote:
>
>> Hi,
>>
>> I support adoption.
>>
>> thanks,
>> Rob
>>
>>
>> On Tue, Dec 5, 2023 at 9:35 PM Deirdre Connolly 
>> wrote:
>>
>>> At the TLS meeting at IETF 118 there was significant support for the
>>> draft 'TLS 1.2 is in Feature Freeze' (
>>> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
>>> call is to confirm this on the list.  Please indicate if you support the
>>> adoption of this draft and are willing to review and contribute text. If
>>> you do not support adoption of this draft please indicate why.  This call
>>> will close on December 20, 2023.
>>>
>>> Thanks,
>>> Deirdre, Joe, and Sean
>>> ___
>>> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[David Schinazi]

I support adoption.
David

On Wed, Dec 6, 2023 at 4:16 PM Rob Sayre  wrote:

> Hi,
>
> I support adoption.
>
> thanks,
> Rob
>
>
> On Tue, Dec 5, 2023 at 9:35 PM Deirdre Connolly 
> wrote:
>
>> At the TLS meeting at IETF 118 there was significant support for the
>> draft 'TLS 1.2 is in Feature Freeze' (
>> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
>> call is to confirm this on the list.  Please indicate if you support the
>> adoption of this draft and are willing to review and contribute text. If
>> you do not support adoption of this draft please indicate why.  This call
>> will close on December 20, 2023.
>>
>> Thanks,
>> Deirdre, Joe, and Sean
>> ___
>> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Rob Sayre]

Hi,

I support adoption.

thanks,
Rob


On Tue, Dec 5, 2023 at 9:35 PM Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, Joe, and Sean
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Bob Beck]

I support adoption and am willing to review.

On Tue, Dec 5, 2023 at 10:34 PM Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, Joe, and Sean
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[John Mattsson]

I support adoption. I also support making TLS 1.2 not recommended, discouraged, 
and deprecated. TLS 1.2 can be anything from quite good to very bad depending 
on configuration. Any work on TLS 1.2 is just delaying deployment of TLS 1.3.

Cheers,
John Preuß Mattsson

From: TLS  on behalf of Christopher Patton 

Date: Wednesday, 6 December 2023 at 17:03
To: Deirdre Connolly 
Cc: TLS@ietf.org 
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
I support adoption.
Chris P.

On Tue, Dec 5, 2023 at 9:34 PM Deirdre Connolly 
mailto:durumcrustu...@gmail.com>> wrote:
At the TLS meeting at IETF 118 there was significant support for the draft 'TLS 
1.2 is in Feature Freeze' 
(https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call is 
to confirm this on the list.  Please indicate if you support the adoption of 
this draft and are willing to review and contribute text. If you do not support 
adoption of this draft please indicate why.  This call will close on December 
20, 2023.

Thanks,
Deirdre, Joe, and Sean
___
TLS mailing list
TLS@ietf.org<mailto: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] Adoption call for 'TLS 1.2 Feature Freeze'

[Christopher Patton]

I support adoption.
Chris P.

On Tue, Dec 5, 2023 at 9:34 PM Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, Joe, and Sean
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Arnaud Taddei]

Speaking of this, just a naïve question, is there anyone who knows about a 
survey with say enterprise organizations on how they see TLS1.2 and their plans 
to move to TLS1.3 and where they struggle with?

If not, would it be an idea to organize a survey?

Just 0.02 CHF

From: TLS  on behalf of Sean Turner 
Date: Wednesday, 6 December 2023 at 14:56
To: Stephen Farrell 
Cc: TLS List 
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

> On Dec 6, 2023, at 07:57, Stephen Farrell  wrote:
>
> Signed PGP part
>
>
> On 06/12/2023 05:33, Deirdre Connolly wrote:
>> At the TLS meeting at IETF 118 there was significant support for the draft
>> 'TLS 1.2 is in Feature Freeze' (
>> https://www.google.com/url?q=https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/=gmail-imap=170247578500=AOvVaw20RCQnXd-R21nczuXpPJrf)
>>   This call
>> is to confirm this on the list.  Please indicate if you support the
>> adoption of this draft and are willing to review and contribute text.
>
> I read the draft and support adopting this. It'll probably
> change as we go in some way or other but it's better that
> the WG figure that out based on a WG draft.
>
> Cheers,
> S.

Yes, it is a starting point. Where we end up is TBD.

spt

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[David Benjamin]

I support adoption and am willing to review.

On Wed, Dec 6, 2023 at 12:34 AM Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, Joe, and Sean
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Nimrod Aviram]

> As the co-author, I support this and am willing to continue working on it
as needed.
Same here.


On Wed, 6 Dec 2023 at 14:51, Salz, Rich 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/
> )
>  This call is to confirm this on the list.  Please indicate if you support
> the adoption of this draft and are willing to review and contribute text.
> If you do not support adoption of this draft please indicate why.  This
> call will close on December 20, 2023.
>
>
>
> As the co-author, I support this and am willing to continue working on it
> as needed.
> ___
> 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] Adoption call for 'TLS 1.2 Feature Freeze'

[Sean Turner]

> On Dec 6, 2023, at 07:57, Stephen Farrell  wrote:
> 
> Signed PGP part
> 
> 
> On 06/12/2023 05:33, Deirdre Connolly wrote:
>> At the TLS meeting at IETF 118 there was significant support for the draft
>> 'TLS 1.2 is in Feature Freeze' (
>> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call
>> is to confirm this on the list.  Please indicate if you support the
>> adoption of this draft and are willing to review and contribute text.
> 
> I read the draft and support adopting this. It'll probably
> change as we go in some way or other but it's better that
> the WG figure that out based on a WG draft.
> 
> Cheers,
> S.

Yes, it is a starting point. Where we end up is TBD.

spt



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Peter Gutmann]

Deirdre Connolly  writes:

>At the TLS meeting at IETF 118 there was significant support for the draft
>'TLS 1.2 is in Feature Freeze' (
>https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call is
>to confirm this on the list.  Please indicate if you support the adoption of
>this draft and are willing to review and contribute text. If you do not
>support adoption of this draft please indicate why.  This call will close on
>December 20, 2023.

I don't see what the point of this draft is.  For anyone who's already made
the switch to TLS 1.3 it's irrelevant, and for people who will have to support
TLS 1.2 deployments probably for the rest of eternity it makes it impossible
to make any changes or fixes.  At best it does nothing, at worst it makes life
very difficult for anyone who has to keep maintaining TLS 1.2 systems.

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Dmitry Belyavsky]

I support adoption of this draft.

On Wed, Dec 6, 2023 at 6:34 AM Deirdre Connolly 
wrote:

> At the TLS meeting at IETF 118 there was significant support for the draft
> 'TLS 1.2 is in Feature Freeze' (
> https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This
> call is to confirm this on the list.  Please indicate if you support the
> adoption of this draft and are willing to review and contribute text. If
> you do not support adoption of this draft please indicate why.  This call
> will close on December 20, 2023.
>
> Thanks,
> Deirdre, Joe, and Sean
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>


-- 
SY, Dmitry Belyavsky
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Arnaud Taddei]

Am comfortable too

From: TLS  on behalf of Salz, Rich 

Date: Wednesday, 6 December 2023 at 13:50
To: Deirdre Connolly , TLS@ietf.org 
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
At the TLS meeting at IETF 118 there was significant support for the draft 'TLS 
1.2 is in Feature Freeze' 
(https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/<https://www.google.com/url?q=https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/__;!!GjvTz_vk!VBr7YTOMzDG9AAXrvLBSL7PusqfSSnMtmbaZuqiSPf85nmVzs0twRHKir-UDnE1vIv9j7iwi4kNg06enIJbaSg$=gmail-imap=170247186100=AOvVaw2L3xsajO-5TrIoOdbCeYfD>)
  This call is to confirm this on the list.  Please indicate if you support the 
adoption of this draft and are willing to review and contribute text. If you do 
not support adoption of this draft please indicate why.  This call will close 
on December 20, 2023.

As the co-author, I support this and am willing to continue working on it as 
needed.

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.


smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Stephen Farrell]

On 06/12/2023 05:33, Deirdre Connolly wrote:

At the TLS meeting at IETF 118 there was significant support for the draft
'TLS 1.2 is in Feature Freeze' (
https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call
is to confirm this on the list.  Please indicate if you support the
adoption of this draft and are willing to review and contribute text.


I read the draft and support adopting this. It'll probably
change as we go in some way or other but it's better that
the WG figure that out based on a WG draft.

Cheers,
S.



OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Salz, Rich]

At the TLS meeting at IETF 118 there was significant support for the draft 'TLS 
1.2 is in Feature Freeze' 
(https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)
  This call is to confirm this on the list.  Please indicate if you support the 
adoption of this draft and are willing to review and contribute text. If you do 
not support adoption of this draft please indicate why.  This call will close 
on December 20, 2023.

As the co-author, I support this and am willing to continue working on it as 
needed.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Deirdre Connolly]

At the TLS meeting at IETF 118 there was significant support for the draft
'TLS 1.2 is in Feature Freeze' (
https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/)  This call
is to confirm this on the list.  Please indicate if you support the
adoption of this draft and are willing to review and contribute text. If
you do not support adoption of this draft please indicate why.  This call
will close on December 20, 2023.

Thanks,
Deirdre, Joe, and Sean
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls