[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Rob Sayre]

Hi,

I have sympathy for the chairs. I do find this one a little frustrating,
although I agree.

I wrote pretty much the same thing, either directly or by quoting Ekr in a
few messages:

https://mailarchive.ietf.org/arch/msg/tls/_e_osuwApqE3jJcXiAxFMsXWdog/
https://mailarchive.ietf.org/arch/msg/tls/R-iG879zBBQgQXlOt9pZ7Tdtc9c/

It's not because I'm a genius, but because the conclusion seems obvious. I
think this kind of intransigence is also one of the things that gives the
list a bad reputation. What a drag. If TLS-LTS works out, we can always
take it up again, as I already wrote (sorry).

thanks,
Rob


On Mon, Dec 2, 2024 at 1:05 PM Sean Turner  wrote:

> This chairs discussed this and we agree that there does not appear that we
> have consensus to adopt the TLS 1.2 Update for Long-term Support I-D.
>
> The chairs would like to note that the WGLC for TLS 1.2 is in Feature
> Freeze (draft-ietf-tls-tls12-frozen) is about to happen shortly. We do not
> believe that progressing TLS 1.2 is in Feature Freeze should affect efforts
> by Peter, if he so chooses, to publish TLS 1.2 Update for Long-term Support
> I-D either by AD sponsor or through the ISE; we will note that the code
> point is already assigned (and has been for years).
>
> spt
>
> > On Nov 5, 2024, at 11:25, Sean Turner  wrote:
> >
> > REQUEST: Let’s not rehash all the context.  It is provided for those who
> might not remember or those that were not around for the duration.
> >
> > CONTEXT: Way back in 2016 after the WG had embarked on developing TLS
> 1.3, Peter Gutmann suggested that another way to “fix” TLS was to specify a
> version of TLS that indicates a “known-good config drawn from the maybe 10
> extension-RFCs”; see [0].  Peter submitted his “TLS 1.2 Update for
> Long-term Support”; see [1]. There was some list discussion; see [2]. Peter
> asked us about adopting the I-D; see [3]. He made changes based on that
> feedback; see [4]. At IETF 98, the WG discussed adopting this I-D and the
> sense of the room was to not adopt the I-D; see [5]. Progress on this
> document was paused while the WG worked on TLS 1.3. Once RFC 8447 was
> published, a code point was assigned for the “tls-lts” extensions; see [6]
> and [7]. Now that we are looking to publish Feature Freeze for TLS 1.2
> [8][9] we want to make sure that the working group sentiment has not
> changed over time so we are running an adoption call for TLS-LTS.
> >
> > MESSAGE: This message is to judge consensus on whether there is support
> to adopt TLS 1.2 Update for Long-term Support; see [1].  If you support
> adoption and are willing to review and contribute text, please send a
> message to the list.  If you do not support adoption of this draft, please
> send a message to the list and indicate why.  This call will close on
> November X, 2024.
> >
> > Thanks,
> > spt
> >
> > [0]
> https://mailarchive.ietf.org/arch/msg/tls/Lr7VwcPCjzDJelUTRTIUJf_8-ww/
> > [1] https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/
> > [2]
> https://mailarchive.ietf.org/arch/msg/tls/r4w75rooy-r8Ky-xXAUoslYTL_U/
> > [3]
> https://mailarchive.ietf.org/arch/msg/tls/6tBftKBmxYz_wUcq79_zH8yDTQk/
> > [4]
> https://mailarchive.ietf.org/arch/msg/tls/aw9BOS4HJ9uum0snEZqSuKA4BYw/
> > [5] https://datatracker.ietf.org/meeting/98/materials/minutes-98-tls-00
> > [6]
> https://mailarchive.ietf.org/arch/msg/tls-reg-review/bP84S3tHSG9gAmc45CLTjpiA0z8/
> > [7]
> https://mailarchive.ietf.org/arch/msg/tls/xmhnVQTckDmUkoxhx4wx1bfpYXM/
> >   Thanks to Peter because he helped us iron out the
> >   wrinkles in the tls-reg-review process.
> > [8] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/
> > [9]
> https://mailarchive.ietf.org/arch/msg/tls/f62yvLL_4mDEsRzAY46L4QLjakU/
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Sean Turner]

This chairs discussed this and we agree that there does not appear that we have 
consensus to adopt the TLS 1.2 Update for Long-term Support I-D.

The chairs would like to note that the WGLC for TLS 1.2 is in Feature Freeze 
(draft-ietf-tls-tls12-frozen) is about to happen shortly. We do not believe 
that progressing TLS 1.2 is in Feature Freeze should affect efforts by Peter, 
if he so chooses, to publish TLS 1.2 Update for Long-term Support I-D either by 
AD sponsor or through the ISE; we will note that the code point is already 
assigned (and has been for years).

spt

> On Nov 5, 2024, at 11:25, Sean Turner  wrote:
> 
> REQUEST: Let’s not rehash all the context.  It is provided for those who 
> might not remember or those that were not around for the duration.
> 
> CONTEXT: Way back in 2016 after the WG had embarked on developing TLS 1.3, 
> Peter Gutmann suggested that another way to “fix” TLS was to specify a 
> version of TLS that indicates a “known-good config drawn from the maybe 10 
> extension-RFCs”; see [0].  Peter submitted his “TLS 1.2 Update for Long-term 
> Support”; see [1]. There was some list discussion; see [2]. Peter asked us 
> about adopting the I-D; see [3]. He made changes based on that feedback; see 
> [4]. At IETF 98, the WG discussed adopting this I-D and the sense of the room 
> was to not adopt the I-D; see [5]. Progress on this document was paused while 
> the WG worked on TLS 1.3. Once RFC 8447 was published, a code point was 
> assigned for the “tls-lts” extensions; see [6] and [7]. Now that we are 
> looking to publish Feature Freeze for TLS 1.2 [8][9] we want to make sure 
> that the working group sentiment has not changed over time so we are running 
> an adoption call for TLS-LTS. 
> 
> MESSAGE: This message is to judge consensus on whether there is support to 
> adopt TLS 1.2 Update for Long-term Support; see [1].  If you support adoption 
> and are willing to review and contribute text, please send a message to the 
> list.  If you do not support adoption of this draft, please send a message to 
> the list and indicate why.  This call will close on November X, 2024. 
> 
> Thanks,
> spt
> 
> [0] https://mailarchive.ietf.org/arch/msg/tls/Lr7VwcPCjzDJelUTRTIUJf_8-ww/ 
> [1] https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/ 
> [2] https://mailarchive.ietf.org/arch/msg/tls/r4w75rooy-r8Ky-xXAUoslYTL_U/ 
> [3] https://mailarchive.ietf.org/arch/msg/tls/6tBftKBmxYz_wUcq79_zH8yDTQk/ 
> [4] https://mailarchive.ietf.org/arch/msg/tls/aw9BOS4HJ9uum0snEZqSuKA4BYw/
> [5] https://datatracker.ietf.org/meeting/98/materials/minutes-98-tls-00 
> [6] 
> https://mailarchive.ietf.org/arch/msg/tls-reg-review/bP84S3tHSG9gAmc45CLTjpiA0z8/
> [7] https://mailarchive.ietf.org/arch/msg/tls/xmhnVQTckDmUkoxhx4wx1bfpYXM/ 
>   Thanks to Peter because he helped us iron out the
>   wrinkles in the tls-reg-review process.
> [8] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/ 
> [9] https://mailarchive.ietf.org/arch/msg/tls/f62yvLL_4mDEsRzAY46L4QLjakU/

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[David Benjamin]

I agree with David's analysis. I think, when reasoning about this, we
should separate the "how to profile TLS 1.2 down" parts from the "extend
TLS 1.2 with more protocol fixes" parts. That's not a knock against those
fixes... it's a good thing! Profiling things down is often a
configuration-only change to existing TLS 1.2 software, is broadly
compatible with existing TLS 1.2 peers, and is covered by existing IETF
documents, like RFC 9325.

In contrast, extending TLS 1.2 requires deploying new code and reasoning
about transitions.

Regarding the DHE extensions, I agree that TLS-LTS shares the same flaws as
RFC 7919.
https://mailarchive.ietf.org/arch/msg/tls/mWWEJdw_SxAIlvZQnsr1_GiAhQY/
discusses this a bit---the one sentence version is that both RFC 7919 and
TLS-LTS would need to have introduced new DHE cipher suite codepoints for
it to work. But given the various other flaws in TLS 1.2 DHE (not currently
addressed by TLS-LTS), I think it's better to do as
draft-ietf-tls-deprecate-obsolete-kex suggests and put our collective
deploy-new-software energies into ECDHE. That has the advantage of being
compatible with existing TLS 1.2, so it isn't even a deploy-new-software
requirement for most folks.

Looking through the rest of draft-gutmann-tls-lts, I see the following
other changes that aren't covered by simply profiling TLS 1.2:
1. Using both x and y coordinates of ECDH as the secret, instead of just x.
2. Increasing the length of the Finished hash
3. Changing the ServerKeyExchange signature payload to hash the whole
transcript thus far
(Anything I've missed?)

The first of these goes against the standard definition of ECDH (e.g. in SP
800-56A), so it seems implementers would need to break their ECDH
abstractions. That, in turn, might have some fun implications w.r.t.
various compliance schemes. Of course, security is more important, but the
security benefit seems unclear to me... y is computable from x up to one
bit. Adding one bit to the output does not seem worth breaking the ECDH
abstraction. Unless there's something I've missed (apologies if I've missed
some text somewhere!), I think we should drop that one.

That leaves 2 and 3. For (2), this WG seems to have largely abandoned
tls-unique as a channel binding in favor of exporters. For (3), the
specific implementation isn't quite right (see my previous email), but
fixable if we change TLS-LTS.

Honestly if we had a time machine, I'd use it to incorporate those (but (3)
done right) into the EMS extension[*]. I think both issues were already
known at the time? But it's not 2015 anymore and it doesn't seem worth the
transition costs now. It's true that smaller code changes are less risky
than larger code changes, but as Watson notes, TLS 1.3 has now a 6 year
headstart to offset that. These issues also don't seem like "urgent
security fixes" per draft-ietf-tls-tls12-frozen.

If we wanted to take just the "profile TLS 1.2 down" bits and just give it
a convenient name, without any wire protocol changes, that might be
worthwhile! "Do you implement Better-TLS-1.2?" is much more understandable
than "Do you implement EMS, RI, AEAD, ECDHE, etc.?" But that doesn't seem
to be what we're discussing here.

Also David

[*] It would have been *extra* nice if the TLS 1.3 anti-downgrade signal
was keyed on better-EMS than TLS 1.3. That would have avoided this mess:
https://mailarchive.ietf.org/arch/msg/tls/pixg5cBXHuwd3MtMIn_xIhWmGGQ/
But we don't have a time machine, so this is moot.


On Wed, Nov 27, 2024 at 10:00 AM David A. Cooper  wrote:

> Hello Peter,
>
> This doesn't really answer my question. I don't have time to read
> through the 18 analysis papers. but [TLS-Analysis-14] describes the
> Triple Handshake attack. Isn't that fixed by the extended_master_secret
> extension (RFC 7627)? If so, then this could be addressed by a guidance
> document that mandated support for extended_master_secret (as RFC 9325
> does), and it wouldn't be an example of a bug that could only be fixed
> by defining a new (tls_lts) extension.
>
> TLS-LTS addresses an issue with DHE cipher suites by sending the full
> set of DH parameters. Why couldn't the issue be addressed by mandating
> that clients offer the supported groups extension with RFC 7919 groups
> and mandating that servers only use those groups? (Another option would
> be to disallow DHE cipher suites as
> https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/
> does.) I understand that draft-gutmann-tls-lts suggests a problem with
> RFC 7919 in cases in which it is not supported by both the client and
> the server, but I don't see how TLS-LTS solves that. What happens if the
> client offers the TLS-TLS extension along with DHE cipher suites, the
> server doesn't support TLS-LTS and selects a DHE cipher suite along with
> the DH group that the client cannot verify? This isn't an issue if the
> client knows the server supports TLS-LTS, but what's the problem with
> using RFC 7919 groups if the client knows the 

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[David A. Cooper]

Hello Peter,

This doesn't really answer my question. I don't have time to read 
through the 18 analysis papers. but [TLS-Analysis-14] describes the 
Triple Handshake attack. Isn't that fixed by the extended_master_secret 
extension (RFC 7627)? If so, then this could be addressed by a guidance 
document that mandated support for extended_master_secret (as RFC 9325 
does), and it wouldn't be an example of a bug that could only be fixed 
by defining a new (tls_lts) extension.


TLS-LTS addresses an issue with DHE cipher suites by sending the full 
set of DH parameters. Why couldn't the issue be addressed by mandating 
that clients offer the supported groups extension with RFC 7919 groups 
and mandating that servers only use those groups? (Another option would 
be to disallow DHE cipher suites as 
https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/ 
does.) I understand that draft-gutmann-tls-lts suggests a problem with 
RFC 7919 in cases in which it is not supported by both the client and 
the server, but I don't see how TLS-LTS solves that. What happens if the 
client offers the TLS-TLS extension along with DHE cipher suites, the 
server doesn't support TLS-LTS and selects a DHE cipher suite along with 
the DH group that the client cannot verify? This isn't an issue if the 
client knows the server supports TLS-LTS, but what's the problem with 
using RFC 7919 groups if the client knows the server supports them?


A lot of what is in draft-gutmann-tls-lts is specifying a profile of TLS 
1.2 (e.g., only use this limited set of cipher suites, only use this one 
elliptic curve, etc.), or is specifying implementation requirements 
(e.g., verify RSA signatures as encode-then-compare). So, most of what 
is in the document is profiling existing capabilities, not describing 
bugs that can only be addressed by defining a new extension.


On 11/26/24 6:20 PM, Peter Gutmann wrote:

David A. Cooper  writes:


what bugs would still remain that TLS-LTS fixes?

This is another thing that's already answered in the draft, for example:

  In particular, this document takes inspiration from numerous
  published analyses of TLS [TLS-Analysis-1] [TLS-Analysis-2]
  [TLS-Analysis-3] [TLS-Analysis-4] [TLS-Analysis-5] [TLS-Analysis-6]
  [TLS-Analysis-7] [TLS-Analysis-8] [TLS-Analysis-9] [TLS-Analysis-10]
  [TLS-Analysis-11] [TLS-Analysis-12] [TLS-Analysis-13]
  [TLS-Analysis-14] [TLS-Analysis-15] [TLS-Analysis-16]
  [TLS-Analysis-17] [TLS-Analysis-18] along with two decades of
  implementation and deployment experience to select a standard
  interoperable feature set that provides the best chance of long-term
  stability and resistance to attack, as well as guidance on
  implementing this feature set in a sound manner.

Actually I'd end up quoting most of the doc which answers the above question,
but for one example:

TLS-LTS sends the full set of DH parameters, X9.42/FIPS 186 style,
not p and g only, PKCS #3 style.  This allows verification of the DH
parameters, which the current format doesn't allow:

[...]
*  The domain parameters MUST either be compared for equivalence to a
   set of known-good parameters provided by an appropriate standards
   body or they MUST be verified as specified in FIPS 186 [FIPS-186].
   Examples of the former may be found in RFC 3526 [RFC3526].

Peter.



___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Peter Gutmann]

David A. Cooper  writes:

>what bugs would still remain that TLS-LTS fixes?

This is another thing that's already answered in the draft, for example:

 In particular, this document takes inspiration from numerous
 published analyses of TLS [TLS-Analysis-1] [TLS-Analysis-2]
 [TLS-Analysis-3] [TLS-Analysis-4] [TLS-Analysis-5] [TLS-Analysis-6]
 [TLS-Analysis-7] [TLS-Analysis-8] [TLS-Analysis-9] [TLS-Analysis-10]
 [TLS-Analysis-11] [TLS-Analysis-12] [TLS-Analysis-13]
 [TLS-Analysis-14] [TLS-Analysis-15] [TLS-Analysis-16]
 [TLS-Analysis-17] [TLS-Analysis-18] along with two decades of
 implementation and deployment experience to select a standard
 interoperable feature set that provides the best chance of long-term
 stability and resistance to attack, as well as guidance on
 implementing this feature set in a sound manner.

Actually I'd end up quoting most of the doc which answers the above question,
but for one example:

TLS-LTS sends the full set of DH parameters, X9.42/FIPS 186 style,
   not p and g only, PKCS #3 style.  This allows verification of the DH
   parameters, which the current format doesn't allow:

   [...]
   *  The domain parameters MUST either be compared for equivalence to a
  set of known-good parameters provided by an appropriate standards
  body or they MUST be verified as specified in FIPS 186 [FIPS-186].
  Examples of the former may be found in RFC 3526 [RFC3526].

Peter.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Peter Gutmann]

Watson Ladd  writes:

>with no formal analysis vs many,

What is there to analyse?  That's a serious question, there's a few very minor
tweaks that address long-standing and well-known problem areas (which is why
I've used the term "no-brainer" in the past), what would you actually analyse?

Peter.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Watson Ladd]

On Tue, Nov 26, 2024, 7:19 PM Peter Gutmann 
wrote:

> Watson Ladd  writes:
>
> >The draft isn't a minor change: it makes handshake and record layer
> changes
> >so everyone would need to install new software and suffer similar compat
> >issues as with a 1.3 update.
>
> This has already been answered several times both in the draft and
> previously
> in the discussion, but here it is again, re-posting one of the previous
> replies:


>   The difference is that TLS 1.3 requires a complete new protocol stack
> while
>   the draft is a minimal tweak to a few known problem areas in TLS 1.2
> while
>   being compatible with existing infrastructure built around 1.2 (or 1.0 in
>   some cases) - newer devices get 1.2TLS, existing ones stay on 1.2/1.0
> until
>   they get replaced.  They're completely different things.
>

How is it more compatible with that infrastructure than 1.3
- it has to support EtM, unless you change to AEAD schemes
- the handshake has a number of changes that need understanding by middle
boxes that care

This seems pretty similar to TLS 1.3 where middle boxes see TLS 1.2
resumption unless they try to be cleaver, but with the disadvantage that
Google engineers are not buying every bit of problematic hardware to see
what works around it.

Do you have any deployment experience to back up your assertions it is more
compatible?



> Peter.
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Peter Gutmann]

Watson Ladd  writes:

>The draft isn't a minor change: it makes handshake and record layer changes
>so everyone would need to install new software and suffer similar compat
>issues as with a 1.3 update.

This has already been answered several times both in the draft and previously
in the discussion, but here it is again, re-posting one of the previous
replies:

  The difference is that TLS 1.3 requires a complete new protocol stack while
  the draft is a minimal tweak to a few known problem areas in TLS 1.2 while
  being compatible with existing infrastructure built around 1.2 (or 1.0 in
  some cases) - newer devices get 1.2TLS, existing ones stay on 1.2/1.0 until
  they get replaced.  They're completely different things.

Peter.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Muhammad Usama Sardar]

On 26.11.24 18:06, Watson Ladd wrote:

But it's starting from 0 years rather than 6 years, with no formal 
analysis vs many, with few to zero implementations vs considerable 
support.


I share this concern. Therefore, I do not support adoption. I think 
nobody would like to formally verify the updates to TLS 1.2 - at least 
not me - sorry!


Let's put all the good energies and great minds in making TLS 1.3 stronger.

Usama



smime.p7s
Description: S/MIME Cryptographic Signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Yaron Sheffer]

This guidance document already exists: https://datatracker.ietf.org/doc/html/rfc9325 Thanks,    Yaron On 26/11/2024, 22:58, "David A. Cooper"  wrote:For me, the question of TLS-LTS or TLS 1.3. If TLS-LTS is a bug fix, then what bugs does it fix that can not be fixed without defining a new extension? If it were replaced with a guidance document that said clients and servers MUST only support cipher suites X, Y, and Z, MUST support encrypt-then-MAC and extended master secret, MUST only offer/support P-256 for ECDH and RFC 7919 groups for FFDH, etc., what bugs would still remain that TLS-LTS fixes? On 11/26/24 6:37 AM, Salz, Rich wrote:>> The draft isn't a minor change: it makes handshake and record>> layer changes so everyone would need to install new software and>> suffer similar compat issues as with a 1.3 update.> Compare a diff for this versus a 1.3 implementation.  The latter is huge.  Also, the former can be considered as a bugfix that closes security holes. TLS 1.3 also fixes things, but it's not really just a bugfix.> >  ___TLS mailing list -- tls@ietf.orgTo unsubscribe send an email to tls-le...@ietf.org ___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[David A. Cooper]

For me, the question of TLS-LTS or TLS 1.3. If TLS-LTS is a bug fix, 
then what bugs does it fix that can not be fixed without defining a new 
extension? If it were replaced with a guidance document that said 
clients and servers MUST only support cipher suites X, Y, and Z, MUST 
support encrypt-then-MAC and extended master secret, MUST only 
offer/support P-256 for ECDH and RFC 7919 groups for FFDH, etc., what 
bugs would still remain that TLS-LTS fixes?


On 11/26/24 6:37 AM, Salz, Rich wrote:

The draft isn't a minor change: it makes handshake and record
layer changes so everyone would need to install new software and
suffer similar compat issues as with a 1.3 update.

Compare a diff for this versus a 1.3 implementation.  The latter is huge.  
Also, the former can be considered as a bugfix that closes security holes. TLS 
1.3 also fixes things, but it's not really just a bugfix.




___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Sean Turner]

> On Nov 26, 2024, at 12:39, Rob Sayre  wrote:
> 
> btw, the adoption call is supposed to end today

Is in indeed closing today. Just a reminder to keep this thread professional.

spt

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Rob Sayre]

On Tue, Nov 26, 2024 at 9:06 AM Watson Ladd  wrote:

>
>
> On Tue, Nov 26, 2024, 11:13 AM Salz, Rich  wrote:
>
>> Either you have new code and break compat or not. That's what really
>> makes the planning hard IMHO. To the extent there is risk associated the
>> widespread use of TLS 1.3 is a significant mitigating factor for
>> undiscovered bugs rolling this out won't have.
>>
>>
>>
>> Spoken by someone who has little experience in enterprise deployments. :)
>>
> True.
>
> What makes the risk lower for LTS?
>
> Enterprises would still need to confirm compatibility of the same
> products, roll out in stages, have a rollback plan etc. and they would have
> much less data on what exactly breaks, harder time getting support in new
> versions or in fixes given the niche nature etc.
>
> I get the draft claims that it's better than the TLS 1.3 given the long
> rollout cycle particularly for embedded (not enterprise) environments. But
> it's starting from 0 years rather than 6 years, with no formal analysis vs
> many, with few to zero implementations vs considerable support.
>

This is a good summary of the debate. btw, the adoption call is supposed to
end today :)

https://mailarchive.ietf.org/arch/msg/tls/EgweLznJ8q6AnuqrFpW0b_kVA2c/

thanks,
Rob
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Stephen Farrell]

Hiya,

Given that this spec requires changes, and assuming (I've not checked)
that there aren't already lots of implementations/deployments after 8
years (since the -00), and that the edhoc protocol has been developed
in the meantime (catering for part of the relevant niche), I am not in
favour of adoption at this time.

If the implementation/deployment situation were better, I'd be willing
to re-consider.

Cheers,
S.



OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Watson Ladd]

On Tue, Nov 26, 2024, 11:13 AM Salz, Rich  wrote:

> Either you have new code and break compat or not. That's what really makes
> the planning hard IMHO. To the extent there is risk associated the
> widespread use of TLS 1.3 is a significant mitigating factor for
> undiscovered bugs rolling this out won't have.
>
>
>
> Spoken by someone who has little experience in enterprise deployments. :)
>
True.

What makes the risk lower for LTS?

Enterprises would still need to confirm compatibility of the same products,
roll out in stages, have a rollback plan etc. and they would have much less
data on what exactly breaks, harder time getting support in new versions or
in fixes given the niche nature etc.

I get the draft claims that it's better than the TLS 1.3 given the long
rollout cycle particularly for embedded (not enterprise) environments. But
it's starting from 0 years rather than 6 years, with no formal analysis vs
many, with few to zero implementations vs considerable support.

Sincerely,
Watson

>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Salz, Rich]

Either you have new code and break compat or not. That's what really makes the 
planning hard IMHO. To the extent there is risk associated the widespread use 
of TLS 1.3 is a significant mitigating factor for undiscovered bugs rolling 
this out won't have.

Spoken by someone who has little experience in enterprise deployments. :)
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Watson Ladd]

On Tue, Nov 26, 2024, 9:38 AM Salz, Rich  wrote:

> > The draft isn't a minor change: it makes handshake and record
> > layer changes so everyone would need to install new software and
> > suffer similar compat issues as with a 1.3 update.
>
> Compare a diff for this versus a 1.3 implementation.  The latter is huge.
> Also, the former can be considered as a bugfix that closes security holes.
> TLS 1.3 also fixes things, but it's not really just a bugfix.
>

Either you have new code and break compat or not. That's what really makes
the planning hard IMHO. To the extent there is risk associated the
widespread use of TLS 1.3 is a significant mitigating factor for
undiscovered bugs rolling this out won't have.

Who is interested in actually implementing and deploying this?

>
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Salz, Rich]

> The draft isn't a minor change: it makes handshake and record 
> layer changes so everyone would need to install new software and 
> suffer similar compat issues as with a 1.3 update.

Compare a diff for this versus a 1.3 implementation.  The latter is huge.  
Also, the former can be considered as a bugfix that closes security holes. TLS 
1.3 also fixes things, but it's not really just a bugfix.


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Alicja Kario]

On Tuesday, 26 November 2024 03:51:20 CET, Watson Ladd wrote:



On Mon, Nov 25, 2024, 8:47 PM Salz, Rich 
 wrote:

Could you explain why thiis way is better than changing to TLS 1.3?
 

It is often the case that organizations will find it easy to 
make a fairly minor change rather than installing a whole new 
version. You’ve never seen this?



The draft isn't a minor change: it makes handshake and record 
layer changes so everyone would need to install new software and 
suffer similar compat issues as with a 1.3 update.


yes, mandating use of EMS, GCM, and rfc7919 is a small change,
changing wire format of messages is not
(I bet that there are middle boxes that will choke on the new 
ServerKeyExchange)


--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Watson Ladd]

On Mon, Nov 25, 2024, 8:47 PM Salz, Rich 
wrote:

>
>- Could you explain why thiis way is better than changing to TLS 1.3?
>
>
>
> It is often the case that organizations will find it easy to make a fairly
> minor change rather than installing a whole new version. You’ve never seen
> this?
>

The draft isn't a minor change: it makes handshake and record layer changes
so everyone would need to install new software and suffer similar compat
issues as with a 1.3 update.

> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Salz, Rich]

  *   Could you explain why thiis way is better than changing to TLS 1.3?

It is often the case that organizations will find it easy to make a fairly 
minor change rather than installing a whole new version. You’ve never seen this?
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Rob Sayre]

I don't know.

Could you explain why thiis way is better than changing to TLS 1.3?

thanks,
Rob


On Mon, Nov 25, 2024 at 5:38 PM Peter Gutmann 
wrote:

> Salz, Rich  writes:
>
> >I'd be willing to provide some rough/initial text if it would help this
> get adopted.
>
> Sure, any input is welcome.
>
> Peter.
>
>
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Peter Gutmann]

Salz, Rich  writes:

>I'd be willing to provide some rough/initial text if it would help this get 
>adopted.

Sure, any input is welcome.

Peter.



___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Salz, Rich]

Andrew Campling mailto:andrew.campl...@419.cons>ulting> writes:
>it should be possible to communicate clearly to implementers and others the
>relative positions of TLS 1.2, TLS-LTS and TLS 1.3 with reference RFC 9325
>and any other relevant documents etc.

On 11/25/24, 6:47 AM, "Peter Gutmann" mailto:pgut...@cs.auckland.ac.nz>> wrote:
> Makes sense, I'd have no problems doing that, although as mentioned for RFC
> 9325 I'd prefer to reference it as "further advice" to avoid confusion over
> the fact that a lot of it covers things that don't exist in -LTS. I'm open to
> suggestions on how to handle this, maybe it's nothing to be concerned about.

I'd be willing to provide some rough/initial text if it would help this get 
adopted.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Peter Gutmann]

Andrew Campling  writes:

>it should be possible to communicate clearly to implementers and others the
>relative positions of TLS 1.2, TLS-LTS and TLS 1.3 with reference RFC 9325
>and any other relevant documents etc.

Makes sense, I'd have no problems doing that, although as mentioned for RFC
9325 I'd prefer to reference it as "further advice" to avoid confusion over
the fact that a lot of it covers things that don't exist in -LTS.  I'm open to
suggestions on how to handle this, maybe it's nothing to be concerned about.

Peter.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Salz, Rich]

If the consensus view of the working group is that the existing communications 
have resulted in mixed messages and some confusion, the adoption of TLS LTS 
could provide a useful vehicle to address that whilst also dealing with the 
various technical points that Peter has already identified in his draft.  By 
expanding the introduction plus sections 3.7  and 4 (or by adding a new 
section), it should be possible to communicate clearly to implementers and 
others the relative positions of TLS 1.2, TLS-LTS and TLS 1.3 with reference 
RFC 9325 and any other relevant documents etc.

This makes sense to me.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Rob Sayre]

Hi,

It doesn't make sense to me, especially considering the WG has adopted

https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/

TLS 1.3 is 6+ years old, for those counting.

Ekr wrote:
> There's nothing stopping people deploying this if they want to and in
fact there
> is already a code point assigned. However, the TLS WG should not take up
this work.

That sounds right to me.

thanks,
Rob


On Fri, Nov 22, 2024 at 9:02 AM Andrew Campling
 wrote:

> On Fri, Nov 22, 2024 at 16:46 Watson Ladd  wrote:
>
>
>
> > How on earth would providing another incompatible set of suggestions
> help? No matter what text was in there it would still raise the question of
> what people should be doing.
>
>
>
> Hi Watson
>
> You may of course not believe that this is a problem or that it is not
> something that the working group needs to solve.  I wouldn’t suggest
> starting with “another incompatible set of suggestions” unless you believe
> that the previous efforts were not useful(?).
>
>
>
> If you agree with the previous post from Yaron that there is a problem
> then it seems reasonable to come up with a proposal on how best to address
> the current lack of clarity.  One way to do that is to incorporate updated
> text into the TLS-LTS draft, and any others that touch on TLS 1.2, making
> sure that it communicates clearly to implementers and others the relative
> positions of TLS 1.2, TLS-LTS and TLS 1.3 with reference RFC 9325 and any
> other relevant documents etc.  Using this consistently from now on ought to
> help.
>
>
>
> There are other ways to address this problem if you agree that it needs to
> be addressed.
>
>
>
>
>
> Andrew
>
>
>
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Watson Ladd]

On Fri, Nov 22, 2024, 9:01 AM Andrew Campling
 wrote:

> On Fri, Nov 22, 2024 at 16:46 Watson Ladd  wrote:
>
>
>
> > How on earth would providing another incompatible set of suggestions
> help? No matter what text was in there it would still raise the question of
> what people should be doing.
>
>
>
> Hi Watson
>
> You may of course not believe that this is a problem or that it is not
> something that the working group needs to solve.  I wouldn’t suggest
> starting with “another incompatible set of suggestions” unless you believe
> that the previous efforts were not useful(?).
>
>
>
> If you agree with the previous post from Yaron that there is a problem
> then it seems reasonable to come up with a proposal on how best to address
> the current lack of clarity.  One way to do that is to incorporate updated
> text into the TLS-LTS draft, and any others that touch on TLS 1.2, making
> sure that it communicates clearly to implementers and others the relative
> positions of TLS 1.2, TLS-LTS and TLS 1.3 with reference RFC 9325 and any
> other relevant documents etc.  Using this consistently from now on ought to
> help.
>
>
>
> There are other ways to address this problem if you agree that it needs to
> be addressed.
>

That presupposes the matter at hand namely adoption of TLS-LTS and that
it's a good idea.

>
>
>
>
> Andrew
>
>
>
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Andrew Campling]

On Fri, Nov 22, 2024 at 16:46 Watson Ladd 
mailto:watsonbl...@gmail.com>> wrote:



> How on earth would providing another incompatible set of suggestions help? No 
> matter what text was in there it would still raise the question of what 
> people should be doing.



Hi Watson
You may of course not believe that this is a problem or that it is not 
something that the working group needs to solve.  I wouldn’t suggest starting 
with “another incompatible set of suggestions” unless you believe that the 
previous efforts were not useful(?).

If you agree with the previous post from Yaron that there is a problem then it 
seems reasonable to come up with a proposal on how best to address the current 
lack of clarity.  One way to do that is to incorporate updated text into the 
TLS-LTS draft, and any others that touch on TLS 1.2, making sure that it 
communicates clearly to implementers and others the relative positions of TLS 
1.2, TLS-LTS and TLS 1.3 with reference RFC 9325 and any other relevant 
documents etc.  Using this consistently from now on ought to help.



There are other ways to address this problem if you agree that it needs to be 
addressed.





Andrew




___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Watson Ladd]

On Fri, Nov 22, 2024 at 6:48 AM Andrew Campling
 wrote:
>
> On 22/11/2024, 13:37, Yaron Sheffer yaronf.i...@gmail.com wrote:
>
> > My point was much broader though: the IETF is sending deployers a bunch
>
> > of mixed messages, and this is on us as a community.
>
> >
>
> > RFC 9325 basically tells them: we prefer that you switch to TLS 1.3, but if
>
> > you absolutely cannot do that, here’s how you can configure the existing
>
> > TLS 1.2 and be secure (as of the time of publication).
>
> >
>
> > TLS-LTS sends a whole different message of course.
>
> >
>
> > And then the working group keeps nibbling at TLS 1.2 with documents like
>
> > draft-ietf-tls-deprecate-obsolete-kex and the earlier “deprecating”
>
> > documents. The KEX document does mention RFC 9325 at one point but
>
> > does not say explicitly which of its requirements are new, making it hard
>
> > for implementers to navigate our recommendations.
>
>
>
>
>
> If the consensus view of the working group is that the existing 
> communications have resulted in mixed messages and some confusion, the 
> adoption of TLS LTS could provide a useful vehicle to address that whilst 
> also dealing with the various technical points that Peter has already 
> identified in his draft.  By expanding the introduction plus sections 3.7  
> and 4 (or by adding a new section), it should be possible to communicate 
> clearly to implementers and others the relative positions of TLS 1.2, TLS-LTS 
> and TLS 1.3 with reference RFC 9325 and any other relevant documents etc.

How on earth would providing another incompatible set of suggestions
help? No matter what text was in there it would still raise the
question of what people should be doing.
>
>
>
> Andrew
>
>
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org



-- 
Astra mortemque praestare gradatim

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Andrew Campling]

On 22/11/2024, 13:37, Yaron Sheffer 
yaronf.i...@gmail.com wrote:
> My point was much broader though: the IETF is sending deployers a bunch
> of mixed messages, and this is on us as a community.
>
> RFC 9325 basically tells them: we prefer that you switch to TLS 1.3, but if
> you absolutely cannot do that, here’s how you can configure the existing
> TLS 1.2 and be secure (as of the time of publication).
>
> TLS-LTS sends a whole different message of course.
>
> And then the working group keeps nibbling at TLS 1.2 with documents like
> draft-ietf-tls-deprecate-obsolete-kex and the earlier “deprecating”
> documents. The KEX document does mention RFC 9325 at one point but
> does not say explicitly which of its requirements are new, making it hard
> for implementers to navigate our recommendations.


If the consensus view of the working group is that the existing communications 
have resulted in mixed messages and some confusion, the adoption of TLS LTS 
could provide a useful vehicle to address that whilst also dealing with the 
various technical points that Peter has already identified in his draft.  By 
expanding the introduction plus sections 3.7  and 4 (or by adding a new 
section), it should be possible to communicate clearly to implementers and 
others the relative positions of TLS 1.2, TLS-LTS and TLS 1.3 with reference 
RFC 9325 and any other relevant documents etc.

Andrew

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Yaron Sheffer]

Hi Peter, Just to put matters straight, the predecessor of RFC 9325, RFC 7525, was published in May 2015. But that doesn’t matter a whole lot now. My point was much broader though: the IETF is sending deployers a bunch of mixed messages, and this is on us as a community. RFC 9325 basically tells them: we prefer that you switch to TLS 1.3, but if you absolutely cannot do that, here’s how you can configure the existing TLS 1.2 and be secure (as of the time of publication). TLS-LTS sends a whole different message of course. And then the working group keeps nibbling at TLS 1.2 with documents like draft-ietf-tls-deprecate-obsolete-kex and the earlier “deprecating” documents. The KEX document does mention RFC 9325 at one point but does not say explicitly which of its requirements are new, making it hard for implementers to navigate our recommendations.  Thanks,    Yaron On 22/11/2024, 12:06, "Peter Gutmann"  wrote:Yaron Sheffer  writes: >Specifically, RFC 9325 [1] published a mere two years ago is not even>referenced in the draft, let alone a comparison made with these deployment>recommendations that were made by the very same IETF. (Yes you can hear my>frustration coming through). In defence of the -LTS draft, RFC 9325 postdates it by six years, so therewasn't anything to reference at the time.  I'm also not certain how muchoverlap there is between the two, for example 9325 contains quite a lot ofstuff (older TLS versions, compression, DTLS, fallback, RC4, NULL ciphersuites, RSA key transport, etc) that has no bearing on what's in -LTS whichmeans it could cause confusion if someone tries to apply it to things thatmostly don't exist in -LTS. Having said that, now that my attention has been drawn to it :-), I'd be happyto include a note along the lines of "further advice on secure use of TLS maybe found in RFC 9325", it would certainly fit in with what -LTS is trying toachieve. Peter.___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Peter Gutmann]

Yaron Sheffer  writes:

>Specifically, RFC 9325 [1] published a mere two years ago is not even
>referenced in the draft, let alone a comparison made with these deployment
>recommendations that were made by the very same IETF. (Yes you can hear my
>frustration coming through).

In defence of the -LTS draft, RFC 9325 postdates it by six years, so there
wasn't anything to reference at the time.  I'm also not certain how much
overlap there is between the two, for example 9325 contains quite a lot of
stuff (older TLS versions, compression, DTLS, fallback, RC4, NULL cipher
suites, RSA key transport, etc) that has no bearing on what's in -LTS which
means it could cause confusion if someone tries to apply it to things that
mostly don't exist in -LTS.

Having said that, now that my attention has been drawn to it :-), I'd be happy
to include a note along the lines of "further advice on secure use of TLS may
be found in RFC 9325", it would certainly fit in with what -LTS is trying to
achieve.

Peter.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Peter Gutmann]

David Benjamin  writes:

>Given that the new client_server_hello_hash fully overlaps with the old
>client_random (totally under the client's control) and then the new params
>overlap with the old server_random (totally under the server's control),
>it's... not immediately obvious to me whether this is fine.

If I'm reading your comment correctly then I'm not sure how that could be
exploitable, an attacker only controls one side and even if they didn't, to
move the signature across from LTS -> TLS you'd have to stuff the entire
client and server hello into the client/server_random contained within them in
order to get the same hash value.  Since this is fixed at 32 bytes, or 64 if
you control both client and server, it's not really possible, and going TLS ->
LTS is a complete non-starter.

Peter.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[David Benjamin]

I did notice one odd thing about the TLS-LTS protocol change (keep in mind
this document is *not* deployment considerations, but a whole new
incompatible mode for TLS 1.2), regarding domain separation. Unless TLS LTS
can fully enforce that the same key is never used for TLS 1.2 LTS and
regular TLS 1.2 (on both the authenticating side and the relying party
side), we need to worry about the security of the two protocols deployed
together.

TLS-LTS changes the signature payload to include the whole transcript so
far:
https://www.ietf.org/archive/id/draft-gutmann-tls-lts-14.html#section-3.1-11.1.1

It also changes the syntax of the ServerDHParams:
https://www.ietf.org/archive/id/draft-gutmann-tls-lts-14.html#section-3.2-2.1.1

Now, signing a transcript is definitely a good move, and TLS's DHE
construction was very much broken. This is why TLS 1.3 fixed both of these.
But when we change the signing payload, we need to think about
domain-separation. It should not be possible to take a signature generated
in one context and substitute it in another context. The TLS 1.2
ServerKeyExchange signing payload is already fragile. ECDHE and DHE param
formats are different, but the cipher suite is not bound into the
signature. I don't have the paper off-hand, but I recall there was a near
miss where the ECDHE and DHE payloads already nearly overlapped. Given that
the new client_server_hello_hash fully overlaps with the old client_random
(totally under the client's control) and then the new params overlap with
the old server_random (totally under the server's control), it's... not
immediately obvious to me whether this is fine.

In comparison, TLS 1.3 prepends a context string and also includes a
64-byte prefix to clear the old client and server randoms. The former
allows domain separation with future signing payloads, and the latter works
around TLS 1.2's lack of a context string. This avoids needing to reason
about overlapping payloads and who controls what, except the minimum needed
to convince ourselves the 64-byte prefix separates from TLS 1.2 well
enough. (Would be nice to avoid that too, but we can't change TLS 1.2's
lack of a context string, only make sure we fix this going forward.)
https://www.rfc-editor.org/rfc/rfc8446#section-4.4.3

Additionally, if making an incompatible change to TLS 1.2 anyway, rather
than adding dh_q to the parameters, I think we've since learned that
negotiating named values is the way to go, hence the addition of FFDH
values into the NamedGroup registry. (Though there are some other issues
with using the same cipher suite values. RFC 7919 did not actually work to
save TLS 1.2 DHE.)

Of course, details like this are not adoption concerns. Adoption is just a
question of whether the WG wants to take on a document as a starting point.
I.e., normally, the question we should answer here is "do we want to extend
TLS 1.2 to apply the smaller protocol fixes?". However, there was talk in
the thread of not wanting to change the protocol anymore, in which case we
would be unable to, say, apply TLS 1.3's fix to this.

On Wed, Nov 20, 2024 at 12:58 PM Yaron Sheffer 
wrote:

> -1. The TLS working group, and this document in particular, has
> consistently ignored the products of the UTA working group. Specifically,
> RFC 9325 [1] published a mere two years ago is not even referenced in the
> draft, let alone a comparison made with these deployment recommendations
> that were made by the very same IETF. (Yes you can hear my frustration
> coming through).
>
>
>
> Thanks,
>
> Yaron
>
>
>
> [1] https://datatracker.ietf.org/doc/rfc9325/
>
>
>
>
>
> On 20/11/2024, 19:27, "Andrew Campling" 
> wrote:
>
> +1, especially given the previous discussion on this topic on the list
> back in 2016.
>
>
>
>
>
> Andrew
>
>
>
> -Original Message-
>
> From: Salz, Rich 
>
> Sent: 05 November 2024 19:01
>
> To: Sean Turner ; TLS List 
>
> Subject: [TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support
>
>
>
> I strongly support adoption.
>
>
>
> I do not understand why anyone would be opposed to the IETF making
> deployment recommendations. I can understand why someone might be bothered
> by the impliciation that *THIS ONE WAY* is the only way to get long-term
> support, especially if it's seen to contradict our encouragement of TLS
> 1.3. But that is an editorial issue that can be easily fixed.
>
>
>
> I would like to see this adopted, a short change cycle, and then advanced
> in the same cluster with our TLS 1.2 is frozen document.
>
>
>
>
>
> ___
>
> TLS mailing list -- tls@ietf.org
>
> To unsubscribe send an email to tls-le...@ietf.org
>
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Yaron Sheffer]

-1. The TLS working group, and this document in particular, has consistently ignored the products of the UTA working group. Specifically, RFC 9325 [1] published a mere two years ago is not even referenced in the draft, let alone a comparison made with these deployment recommendations that were made by the very same IETF. (Yes you can hear my frustration coming through). Thanks,    Yaron [1] https://datatracker.ietf.org/doc/rfc9325/  On 20/11/2024, 19:27, "Andrew Campling"  wrote:+1, especially given the previous discussion on this topic on the list back in 2016.   Andrew -Original Message-From: Salz, Rich <rs...@akamai.com> Sent: 05 November 2024 19:01To: Sean Turner <s...@sn3rd.com>; TLS List <tls@ietf.org>Subject: [TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support I strongly support adoption. I do not understand why anyone would be opposed to the IETF making deployment recommendations. I can understand why someone might be bothered by the impliciation that *THIS ONE WAY* is the only way to get long-term support, especially if it's seen to contradict our encouragement of TLS 1.3. But that is an editorial issue that can be easily fixed. I would like to see this adopted, a short change cycle, and then advanced in the same cluster with our TLS 1.2 is frozen document.  ___TLS mailing list -- tls@ietf.orgTo unsubscribe send an email to tls-le...@ietf.org ___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Andrew Campling]

+1, especially given the previous discussion on this topic on the list back in 
2016. 


Andrew

-Original Message-
From: Salz, Rich  
Sent: 05 November 2024 19:01
To: Sean Turner ; TLS List 
Subject: [TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

I strongly support adoption.

I do not understand why anyone would be opposed to the IETF making deployment 
recommendations. I can understand why someone might be bothered by the 
impliciation that *THIS ONE WAY* is the only way to get long-term support, 
especially if it's seen to contradict our encouragement of TLS 1.3. But that is 
an editorial issue that can be easily fixed.

I would like to see this adopted, a short change cycle, and then advanced in 
the same cluster with our TLS 1.2 is frozen document.


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Sean Turner]

Reminder that this adoption call is still on going.

spt

> On Nov 5, 2024, at 16:26, Sean Turner  wrote:
> 
> 
> 
>> On Nov 5, 2024, at 16:25, Sean Turner  wrote:
>> 
>> REQUEST: Let’s not rehash all the context.  It is provided for those who 
>> might not remember or those that were not around for the duration.
>> 
>> CONTEXT: Way back in 2016 after the WG had embarked on developing TLS 1.3, 
>> Peter Gutmann suggested that another way to “fix” TLS was to specify a 
>> version of TLS that indicates a “known-good config drawn from the maybe 10 
>> extension-RFCs”; see [0].  Peter submitted his “TLS 1.2 Update for Long-term 
>> Support”; see [1]. There was some list discussion; see [2]. Peter asked us 
>> about adopting the I-D; see [3]. He made changes based on that feedback; see 
>> [4]. At IETF 98, the WG discussed adopting this I-D and the sense of the 
>> room was to not adopt the I-D; see [5]. Progress on this document was paused 
>> while the WG worked on TLS 1.3. Once RFC 8447 was published, a code point 
>> was assigned for the “tls-lts” extensions; see [6] and [7]. Now that we are 
>> looking to publish Feature Freeze for TLS 1.2 [8][9] we want to make sure 
>> that the working group sentiment has not changed over time so we are running 
>> an adoption call for TLS-LTS. 
>> 
>> MESSAGE: This message is to judge consensus on whether there is support to 
>> adopt TLS 1.2 Update for Long-term Support; see [1].  If you support 
>> adoption and are willing to review and contribute text, please send a 
>> message to the list.  If you do not support adoption of this draft, please 
>> send a message to the list and indicate why.  This call will close on 
>> November X, 2024. 
> 
> Whoops November 26, 2024.
> 
>> Thanks,
>> spt
>> 
>> [0] https://mailarchive.ietf.org/arch/msg/tls/Lr7VwcPCjzDJelUTRTIUJf_8-ww/ 
>> [1] https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/ 
>> [2] https://mailarchive.ietf.org/arch/msg/tls/r4w75rooy-r8Ky-xXAUoslYTL_U/ 
>> [3] https://mailarchive.ietf.org/arch/msg/tls/6tBftKBmxYz_wUcq79_zH8yDTQk/ 
>> [4] https://mailarchive.ietf.org/arch/msg/tls/aw9BOS4HJ9uum0snEZqSuKA4BYw/
>> [5] https://datatracker.ietf.org/meeting/98/materials/minutes-98-tls-00 
>> [6] 
>> https://mailarchive.ietf.org/arch/msg/tls-reg-review/bP84S3tHSG9gAmc45CLTjpiA0z8/
>> [7] https://mailarchive.ietf.org/arch/msg/tls/xmhnVQTckDmUkoxhx4wx1bfpYXM/ 
>>  Thanks to Peter because he helped us iron out the
>>  wrinkles in the tls-reg-review process.
>> [8] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/ 
>> [9] https://mailarchive.ietf.org/arch/msg/tls/f62yvLL_4mDEsRzAY46L4QLjakU/
> 

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Peter Gutmann]

David A. Cooper  writes:

>It would also be inappropriate to adopt it as a WG document, especially as a
>standards track document,

I was thinking more informational.  Actually I'm not too fussed over what
category it's in, as long as it gets out of its current limbo.

>It would be contrary to the goal of this draft to suggest that those who have
>been using it since 2016 should not modify their implementations to align
>with changes made by the WG.

It was put on hold so as not to interfere with the TLS 1.3 process (and then
admittedly I forgot to un-hold it afterwards).  It seems like you're saying
that doing what the WG requested now makes it ineligible for consideration by
the WG.

Another point is that it's been around for eight years, it's not like people
haven't had more than enough opportunity to comment on it and suggest changes
in that time.  The current late-to-the-party response seems to be mostly a
chorus of "I haven't read it but I know I don't like it".

Peter.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Alicja Kario]

On Thursday, 7 November 2024 14:58:02 CET, Peter Gutmann wrote:

The current late-to-the-party response seems to be mostly a
chorus of "I haven't read it but I know I don't like it".


There is no need for personal attacks.
--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[David A. Cooper]

I am also against adoption.

I would not be against a draft that made deployment recommendations, if 
RFC 9325 was considered insufficient. (Although I don't like the idea of 
suggesting that TLS 1.2 without support for quantum-resistant 
cryptography is a recommended long-term solution.) However, as others 
have noted, this draft is not making deployment recommendations, it is 
specifying a new extension that signals the use of a slightly modified 
version of TLS 1.2. I also agree that not adopting this draft does not 
prevent people from using it, let alone continuing to use TLS 1.2.


Even if I thought the idea of having an extension to signal the use of a 
slightly modified version of TLS 1.2 were a good idea, I believe there 
is another reason that it would be best for this WG not to adopt the 
draft. If the draft were adopted by the WG, then it would need to be 
open for the WG to make technical changes to it. However, Peter 
indicated in 2018 [0] that the extension defined in 
draft-gutmann-tls-lts had been in use since 2016. It would be contrary 
to the goal of this draft to suggest that those who have been using it 
since 2016 should not modify their implementations to align with changes 
made by the WG. It would also be inappropriate to adopt it as a WG 
document, especially as a standards track document, and then effectively 
declare that no technical changes can be made.


[0] https://mailarchive.ietf.org/arch/msg/tls/q7up_-tJH3ysD5Xip1mKGtTLKbg/

On 11/5/24 1:45 PM, Eric Rescorla wrote:

I am against adoption.

As Nick and Watson note, this is not just a profile of TLS 1.2 but is 
rather a set of negotiated with a new extension code point, i.e., it's 
effectively a new version of TLS with as yet only lightly analyzed 
security properties. We already have a new version of TLS which has 
been heavily analyzed and widely deployed, namely TLS 1.3.


There's nothing stopping people deploying this if they want to and in 
fact there is already a code point assigned. However, the TLS WG 
should not take up this work.


-Ekr

On Tue, Nov 5, 2024 at 1:21 PM Arnaud Taddei 
 wrote:


I do support the adoption of this draft.

This draft is a very good product and the details and care that
this draft exhibits is in itself a testimony of someone who has a
real production experience, is realistic and pragmatic.

There is a big difference between
patching an endpoint to a variation of TLS1.2 which is meant to
work in a ’TLS1.2 designed environment”
Vs
patching an endpoint to TLS1.3 in an environment that was ’TLS1.2
designed environment’

If the organisation that needs to manage a security risk is given
a choice of
1) Patch to TLS-LTS
2) Patch to TLS1.3

Any risk manager is going to ask the qualification of the
implications on both and the result will be that 1) will be far
less intrusive and risky than 2)

Moreover the bench-test platform that the solution needs to go
through to prove its production readiness may not be able to
support TLS1.3 at all.

Not adopting this draft leaves only one choice to any customer
with no guarantees that the patching to TLS1.3 will work in its
TLS1.2 designed end-to-end environment at a manageable time, cost
and ‘go to production’ or ‘go to market’ time, and risk.

Worse, it could have unanticipated consequences like breaking
compliancy to regulations, to safety and I can just imagine how it
could move the risks from bits and bytes to blood and flesh.

My 0.02 Swiss francs

*Arnaud Taddei*
Global Security Strategist | Enterprise Security Group

*mobile:* +41 79 506 1129
Geneva, Switzerland
arnaud.tad...@broadcom.com | broadcom.com 


On 5 Nov 2024, at 19:48, Nick Harper  wrote:

I understand the stated goal of this draft to be to provide a way
for hard-to-update endpoints to keep using TLS 1.2 in a
secure way. The idea of a document that describes how to safely
deploy TLS 1.2 sounds like a good idea, e.g. "use only these
cipher suites, require EMS and RI, etc". This draft is not that.

This draft makes changes to the TLS handshake protocol, which
undermines the goal of supporting hard-to-update endpoints. The
two changes made to the protocol are also addressed by RFC 8446.
If endpoints need to be updated to support TLS-LTS, it would make
more sense to update them to support TLS 1.3 than TLS-LTS.

The rationale section (3.7) of the draft presents two reasons for
using TLS-LTS over TLS 1.3. The first is the slow deployment
cadence of a new protocol. LTS requires a change to the protocol
and deployment of that new change, no different from 1.3. The
second reason is fear of the unknown in 1.3: "TLS 1.3 is an
almost entirely new protocol. As such, it rolls back the 20 years
of experience that we have with all the things that can go wrong
in TLS". The 20 ye

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Christopher Wood]

I do not support adoption.

Best,
Chris

> On Nov 5, 2024, at 11:25 AM, Sean Turner  wrote:
> 
> REQUEST: Let’s not rehash all the context.  It is provided for those who 
> might not remember or those that were not around for the duration.
> 
> CONTEXT: Way back in 2016 after the WG had embarked on developing TLS 1.3, 
> Peter Gutmann suggested that another way to “fix” TLS was to specify a 
> version of TLS that indicates a “known-good config drawn from the maybe 10 
> extension-RFCs”; see [0].  Peter submitted his “TLS 1.2 Update for Long-term 
> Support”; see [1]. There was some list discussion; see [2]. Peter asked us 
> about adopting the I-D; see [3]. He made changes based on that feedback; see 
> [4]. At IETF 98, the WG discussed adopting this I-D and the sense of the room 
> was to not adopt the I-D; see [5]. Progress on this document was paused while 
> the WG worked on TLS 1.3. Once RFC 8447 was published, a code point was 
> assigned for the “tls-lts” extensions; see [6] and [7]. Now that we are 
> looking to publish Feature Freeze for TLS 1.2 [8][9] we want to make sure 
> that the working group sentiment has not changed over time so we are running 
> an adoption call for TLS-LTS.
> 
> MESSAGE: This message is to judge consensus on whether there is support to 
> adopt TLS 1.2 Update for Long-term Support; see [1].  If you support adoption 
> and are willing to review and contribute text, please send a message to the 
> list.  If you do not support adoption of this draft, please send a message to 
> the list and indicate why.  This call will close on November X, 2024.
> 
> Thanks,
> spt
> 
> [0] https://mailarchive.ietf.org/arch/msg/tls/Lr7VwcPCjzDJelUTRTIUJf_8-ww/
> [1] https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/
> [2] https://mailarchive.ietf.org/arch/msg/tls/r4w75rooy-r8Ky-xXAUoslYTL_U/
> [3] https://mailarchive.ietf.org/arch/msg/tls/6tBftKBmxYz_wUcq79_zH8yDTQk/
> [4] https://mailarchive.ietf.org/arch/msg/tls/aw9BOS4HJ9uum0snEZqSuKA4BYw/
> [5] https://datatracker.ietf.org/meeting/98/materials/minutes-98-tls-00
> [6] 
> https://mailarchive.ietf.org/arch/msg/tls-reg-review/bP84S3tHSG9gAmc45CLTjpiA0z8/
> [7] https://mailarchive.ietf.org/arch/msg/tls/xmhnVQTckDmUkoxhx4wx1bfpYXM/
>   Thanks to Peter because he helped us iron out the
>   wrinkles in the tls-reg-review process.
> [8] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/
> [9] https://mailarchive.ietf.org/arch/msg/tls/f62yvLL_4mDEsRzAY46L4QLjakU/
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Richard Barnes]

I concur with everything Nick says here.

Deployment guidance is fine.  We should not adopt any document that would
require code changes to implement.

We should not adopt this document in its current form.

--Richard

On Tue, Nov 5, 2024 at 7:49 PM Nick Harper  wrote:

> I understand the stated goal of this draft to be to provide a way for
> hard-to-update endpoints to keep using TLS 1.2 in a secure way. The idea of
> a document that describes how to safely deploy TLS 1.2 sounds like a good
> idea, e.g. "use only these cipher suites, require EMS and RI, etc". This
> draft is not that.
>
> This draft makes changes to the TLS handshake protocol, which undermines
> the goal of supporting hard-to-update endpoints. The two changes made to
> the protocol are also addressed by RFC 8446. If endpoints need to be
> updated to support TLS-LTS, it would make more sense to update them to
> support TLS 1.3 than TLS-LTS.
>
> The rationale section (3.7) of the draft presents two reasons for using
> TLS-LTS over TLS 1.3. The first is the slow deployment cadence of a new
> protocol. LTS requires a change to the protocol and deployment of that new
> change, no different from 1.3. The second reason is fear of the unknown in
> 1.3: "TLS 1.3 is an almost entirely new protocol. As such, it rolls back
> the 20 years of experience that we have with all the things that can go
> wrong in TLS". The 20 years of all the things that can go wrong in TLS were
> due to unsound cryptographic decisions. The research and analysis that
> found those 20 years of issues was applied to the design of 1.3 to avoid
> making the same mistakes. 1.3 doesn't roll back that experience, and we now
> have over 8 years of experience with 1.3.
>
> I do not support adoption of the draft in this format. If the draft made
> no changes to the TLS 1.2 protocol and were deployable only through
> configuration changes (e.g. a fixed list of cipher suites and extensions),
> I would probably support it.
>
> On Tue, Nov 5, 2024 at 11:02 AM Salz, Rich  40akamai@dmarc.ietf.org> wrote:
>
>> I strongly support adoption.
>>
>> I do not understand why anyone would be opposed to the IETF making
>> deployment recommendations. I can understand why someone might be bothered
>> by the impliciation that *THIS ONE WAY* is the only way to get long-term
>> support, especially if it's seen to contradict our encouragement of TLS
>> 1.3. But that is an editorial issue that can be easily fixed.
>>
>> I would like to see this adopted, a short change cycle, and then advanced
>> in the same cluster with our TLS 1.2 is frozen document.
>>
>>
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Bas Westerbaan]

I do not support adoption.

On Tue, Nov 5, 2024 at 5:27 PM Sean Turner  wrote:

> REQUEST: Let’s not rehash all the context.  It is provided for those who
> might not remember or those that were not around for the duration.
>
> CONTEXT: Way back in 2016 after the WG had embarked on developing TLS 1.3,
> Peter Gutmann suggested that another way to “fix” TLS was to specify a
> version of TLS that indicates a “known-good config drawn from the maybe 10
> extension-RFCs”; see [0].  Peter submitted his “TLS 1.2 Update for
> Long-term Support”; see [1]. There was some list discussion; see [2]. Peter
> asked us about adopting the I-D; see [3]. He made changes based on that
> feedback; see [4]. At IETF 98, the WG discussed adopting this I-D and the
> sense of the room was to not adopt the I-D; see [5]. Progress on this
> document was paused while the WG worked on TLS 1.3. Once RFC 8447 was
> published, a code point was assigned for the “tls-lts” extensions; see [6]
> and [7]. Now that we are looking to publish Feature Freeze for TLS 1.2
> [8][9] we want to make sure that the working group sentiment has not
> changed over time so we are running an adoption call for TLS-LTS.
>
> MESSAGE: This message is to judge consensus on whether there is support to
> adopt TLS 1.2 Update for Long-term Support; see [1].  If you support
> adoption and are willing to review and contribute text, please send a
> message to the list.  If you do not support adoption of this draft, please
> send a message to the list and indicate why.  This call will close on
> November X, 2024.
>
> Thanks,
> spt
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/Lr7VwcPCjzDJelUTRTIUJf_8-ww/
> [1] https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/
> [2] https://mailarchive.ietf.org/arch/msg/tls/r4w75rooy-r8Ky-xXAUoslYTL_U/
> [3] https://mailarchive.ietf.org/arch/msg/tls/6tBftKBmxYz_wUcq79_zH8yDTQk/
> [4] https://mailarchive.ietf.org/arch/msg/tls/aw9BOS4HJ9uum0snEZqSuKA4BYw/
> [5] https://datatracker.ietf.org/meeting/98/materials/minutes-98-tls-00
> [6]
> https://mailarchive.ietf.org/arch/msg/tls-reg-review/bP84S3tHSG9gAmc45CLTjpiA0z8/
> [7] https://mailarchive.ietf.org/arch/msg/tls/xmhnVQTckDmUkoxhx4wx1bfpYXM/
>Thanks to Peter because he helped us iron out the
>wrinkles in the tls-reg-review process.
> [8] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/
> [9] https://mailarchive.ietf.org/arch/msg/tls/f62yvLL_4mDEsRzAY46L4QLjakU/
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Peter Gutmann]

Arnaud Taddei writes:

>There is a big difference between
>
>patching an endpoint to a variation of TLS1.2 which is meant to work in a ’
>TLS1.2 designed environment”
>
>Vs
>
>patching an endpoint to TLS1.3 in an environment that was ’TLS1.2 designed
>environment’

Yup, and that's the intent of the draft, since some industries are going to be
living in a TLS 1.2 environment for some time (as well as TLS 1.0, but I'm not
touching that one), this will try and make it the least problematic TLS 1.2
environment, i.e. it addresses well-known problem areas without making any
significant changes - it was explicitly written not to include anything new 
(new algorithms, new signature types, new hashes, whatever), it's all existing
algorithms that have been around forever, just with minor tweaks like sending
the full domain parameters to allow verification of the DH values, which have
been a problem in the past because of the PKCS #3-based origins of SSLv2 where
this came from.

Peter.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Pascal Urien]

Hi Peter

I've never seen TLS 1.3 in an embedded device.  By "embedded device" do you
>
mean a Linux box, or something running RTEMS, uC/OS, ThreadX, or similar?
>

TLS 1.3  in PSK mode for secure element (smartcard) is described in
https://datatracker.ietf.org/doc/draft-urien-tls-se/

Implementation for javacard is there
https://github.com/purien/TLS-SE

Presentation at IETF120 HOTRFC is there
https://www.youtube.com/watch?v=0cLtrcMNjQ4

Pascal


>
> Peter.
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Martin Thomson]

On Tue, Nov 5, 2024, at 16:25, Sean Turner wrote:
> MESSAGE: This message is to judge consensus on whether there is support 
> to adopt TLS 1.2 Update for Long-term Support; 

https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls12-frozen-02 says:

"no new features will be approved for TLS 1.2"

I'll leave it to the chairs to judge whether this statement has consensus, but 
I support that statement.  We should not adopt this draft.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Viktor Dukhovni]

On Tue, Nov 05, 2024 at 07:01:13PM +, Salz, Rich wrote:

> I strongly support adoption.
> 
> I do not understand why anyone would be opposed to the IETF making
> deployment recommendations. I can understand why someone might be
> bothered by the impliciation that *THIS ONE WAY* is the only way to
> get long-term support, especially if it's seen to contradict our
> encouragement of TLS 1.3. But that is an editorial issue that can be
> easily fixed.
> 
> I would like to see this adopted, a short change cycle, and then
> advanced in the same cluster with our TLS 1.2 is frozen document.

I support adoption.

-- 
Viktor.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Peter Gutmann]

Eric Rescorla  writes:

>it's effectively a new version of TLS with as yet only lightly analyzed
>security properties.

Are you sure you've read the right document?  "A new version of TLS"?  It's
existing extensions, a few minor tweaks to deal with long-known problem areas,
and some implementation advice, also to deal with long-known problem areas.

Peter.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Peter Gutmann]

Watson Ladd  writes:

>TLS 1.3 has widely been implemented and depoloyed across embedded devices and
>has much better analysis. You'd still need to patch devices for this to be
>deployable.

I've never seen TLS 1.3 in an embedded device.  By "embedded device" do you
mean a Linux box, or something running RTEMS, uC/OS, ThreadX, or similar?

Peter.
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Peter Gutmann]

Nick Harper  writes:

>If endpoints need to be updated to support TLS-LTS, it would make more sense
>to update them to support TLS 1.3 than TLS-LTS.

The difference is that TLS 1.3 requires a complete new protocol stack while
the draft is a minimal tweak to a few known problem areas in TLS 1.2 while
being compatible with existing infrastructure built around 1.2 (or 1.0 in some
cases) - newer devices get 1.2TLS, existing ones stay on 1.2/1.0 until they
get replaced.  They're completely different things.

Peter.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Thom Wiggers]

Hi all,

I don’t think that we should consider saying that TLS 1.2 (or a variant) is an 
okay and safe choice for the next 10+ years while this protocol will not 
receive post-quantum security updates (if we stick with “no PQ for TLS 1.2”). I 
realize that integrating PQC in a “LTS” deployment might not be feasible/stable 
enough at this moment, but I fear that putting out a “TLS-LTS” gives people 
“permission" to ossify on non-PQC (as it will not be backported) for a 
considerable amount of time longer.

For this reason, and the same reasons as stated by Eric, Nick and Watson, I am 
against adoption of this document (or at least in this form). There may be 
contents of this document that we might consider extracting 

Cheers,

Thom

> Op 6 nov 2024, om 06:45 heeft Eric Rescorla  het volgende 
> geschreven:
> 
> I am against adoption. 
> 
> As Nick and Watson note, this is not just a profile of TLS 1.2 but is rather 
> a set of negotiated with a new extension code point, i.e., it's effectively a 
> new version of TLS with as yet only lightly analyzed security properties. We 
> already have a new version of TLS which has been heavily analyzed and widely 
> deployed, namely TLS 1.3.
> 
> There's nothing stopping people deploying this if they want to and in fact 
> there is already a code point assigned. However, the TLS WG should not take 
> up this work.
> 
> -Ekr
> 
> On Tue, Nov 5, 2024 at 1:21 PM Arnaud Taddei 
>  > wrote:
>> I do support the adoption of this draft. 
>> 
>> This draft is a very good product and the details and care that this draft 
>> exhibits is in itself a testimony of someone who has a real production 
>> experience, is realistic and pragmatic. 
>> 
>> There is a big difference between 
>>  patching an endpoint to a variation of TLS1.2 which is meant to work in 
>> a ’TLS1.2 designed environment” 
>> Vs 
>>  patching an endpoint to TLS1.3 in an environment that was ’TLS1.2 
>> designed environment’
>> 
>> If the organisation that needs to manage a security risk is given a choice 
>> of 
>> 1) Patch to TLS-LTS
>> 2) Patch to TLS1.3 
>> 
>> Any risk manager is going to ask the qualification of the implications on 
>> both and the result will be that 1) will be far less intrusive and risky 
>> than 2)
>> 
>> Moreover the bench-test platform that the solution needs to go through to 
>> prove its production readiness may not be able to support TLS1.3 at all.
>> 
>> Not adopting this draft leaves only one choice to any customer with no 
>> guarantees that the patching to TLS1.3 will work in its TLS1.2 designed 
>> end-to-end environment at a manageable time, cost and ‘go to production’ or 
>> ‘go to market’ time, and risk.
>> 
>> Worse, it could have unanticipated consequences like breaking compliancy to 
>> regulations, to safety and I can just imagine how it could move the risks 
>> from bits and bytes to blood and flesh.
>> 
>> My 0.02 Swiss francs
>> 
>> Arnaud Taddei
>> Global Security Strategist | Enterprise Security Group
>> 
>> mobile: +41 79 506 1129 
>> Geneva, Switzerland
>> arnaud.tad...@broadcom.com  | 
>> broadcom.com 
>> 
>>> On 5 Nov 2024, at 19:48, Nick Harper >> > wrote:
>>> 
>>> I understand the stated goal of this draft to be to provide a way for 
>>> hard-to-update endpoints to keep using TLS 1.2 in a secure way. The idea of 
>>> a document that describes how to safely deploy TLS 1.2 sounds like a good 
>>> idea, e.g. "use only these cipher suites, require EMS and RI, etc". This 
>>> draft is not that.
>>> 
>>> This draft makes changes to the TLS handshake protocol, which undermines 
>>> the goal of supporting hard-to-update endpoints. The two changes made to 
>>> the protocol are also addressed by RFC 8446. If endpoints need to be 
>>> updated to support TLS-LTS, it would make more sense to update them to 
>>> support TLS 1.3 than TLS-LTS.
>>> 
>>> The rationale section (3.7) of the draft presents two reasons for using 
>>> TLS-LTS over TLS 1.3. The first is the slow deployment cadence of a new 
>>> protocol. LTS requires a change to the protocol and deployment of that new 
>>> change, no different from 1.3. The second reason is fear of the unknown in 
>>> 1.3: "TLS 1.3 is an almost entirely new protocol. As such, it rolls back 
>>> the 20 years of experience that we have with all the things that can go 
>>> wrong in TLS". The 20 years of all the things that can go wrong in TLS were 
>>> due to unsound cryptographic decisions. The research and analysis that 
>>> found those 20 years of issues was applied to the design of 1.3 to avoid 
>>> making the same mistakes. 1.3 doesn't roll back that experience, and we now 
>>> have over 8 years of experience with 1.3.
>>> 
>>> I do not support adoption of the draft in this format. If the draft made no 
>>> changes to the TLS 1.2 protocol and were deployable only through 
>>> configuration changes (e.g.

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Eric Rescorla]

I am against adoption.

As Nick and Watson note, this is not just a profile of TLS 1.2 but is
rather a set of negotiated with a new extension code point, i.e., it's
effectively a new version of TLS with as yet only lightly analyzed security
properties. We already have a new version of TLS which has been heavily
analyzed and widely deployed, namely TLS 1.3.

There's nothing stopping people deploying this if they want to and in fact
there is already a code point assigned. However, the TLS WG should not take
up this work.

-Ekr

On Tue, Nov 5, 2024 at 1:21 PM Arnaud Taddei  wrote:

> I do support the adoption of this draft.
>
> This draft is a very good product and the details and care that this draft
> exhibits is in itself a testimony of someone who has a real production
> experience, is realistic and pragmatic.
>
> There is a big difference between
> patching an endpoint to a variation of TLS1.2 which is meant to work in a
> ’TLS1.2 designed environment”
> Vs
> patching an endpoint to TLS1.3 in an environment that was ’TLS1.2 designed
> environment’
>
> If the organisation that needs to manage a security risk is given a choice
> of
> 1) Patch to TLS-LTS
> 2) Patch to TLS1.3
>
> Any risk manager is going to ask the qualification of the implications on
> both and the result will be that 1) will be far less intrusive and risky
> than 2)
>
> Moreover the bench-test platform that the solution needs to go through to
> prove its production readiness may not be able to support TLS1.3 at all.
>
> Not adopting this draft leaves only one choice to any customer with no
> guarantees that the patching to TLS1.3 will work in its TLS1.2 designed
> end-to-end environment at a manageable time, cost and ‘go to production’ or
> ‘go to market’ time, and risk.
>
> Worse, it could have unanticipated consequences like breaking compliancy
> to regulations, to safety and I can just imagine how it could move the
> risks from bits and bytes to blood and flesh.
>
> My 0.02 Swiss francs
>
> *Arnaud Taddei*
> Global Security Strategist | Enterprise Security Group
>
> *mobile:* +41 79 506 1129
> Geneva, Switzerland
> arnaud.tad...@broadcom.com | broadcom.com
>
> On 5 Nov 2024, at 19:48, Nick Harper  wrote:
>
> I understand the stated goal of this draft to be to provide a way for
> hard-to-update endpoints to keep using TLS 1.2 in a secure way. The idea of
> a document that describes how to safely deploy TLS 1.2 sounds like a good
> idea, e.g. "use only these cipher suites, require EMS and RI, etc". This
> draft is not that.
>
> This draft makes changes to the TLS handshake protocol, which undermines
> the goal of supporting hard-to-update endpoints. The two changes made to
> the protocol are also addressed by RFC 8446. If endpoints need to be
> updated to support TLS-LTS, it would make more sense to update them to
> support TLS 1.3 than TLS-LTS.
>
> The rationale section (3.7) of the draft presents two reasons for using
> TLS-LTS over TLS 1.3. The first is the slow deployment cadence of a new
> protocol. LTS requires a change to the protocol and deployment of that new
> change, no different from 1.3. The second reason is fear of the unknown in
> 1.3: "TLS 1.3 is an almost entirely new protocol. As such, it rolls back
> the 20 years of experience that we have with all the things that can go
> wrong in TLS". The 20 years of all the things that can go wrong in TLS were
> due to unsound cryptographic decisions. The research and analysis that
> found those 20 years of issues was applied to the design of 1.3 to avoid
> making the same mistakes. 1.3 doesn't roll back that experience, and we now
> have over 8 years of experience with 1.3.
>
> I do not support adoption of the draft in this format. If the draft made
> no changes to the TLS 1.2 protocol and were deployable only through
> configuration changes (e.g. a fixed list of cipher suites and extensions),
> I would probably support it.
>
> On Tue, Nov 5, 2024 at 11:02 AM Salz, Rich  40akamai@dmarc.ietf.org> wrote:
>
>> I strongly support adoption.
>>
>> I do not understand why anyone would be opposed to the IETF making
>> deployment recommendations. I can understand why someone might be bothered
>> by the impliciation that *THIS ONE WAY* is the only way to get long-term
>> support, especially if it's seen to contradict our encouragement of TLS
>> 1.3. But that is an editorial issue that can be easily fixed.
>>
>> I would like to see this adopted, a short change cycle, and then advanced
>> in the same cluster with our TLS 1.2 is frozen document.
>>
>>
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
>
>
> This electronic communication and the information and any files
> transmitted with it, or attached to it, are confidential and are intended
> solely for the

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Arnaud Taddei]

I do support the adoption of this draft. 

This draft is a very good product and the details and care that this draft 
exhibits is in itself a testimony of someone who has a real production 
experience, is realistic and pragmatic. 

There is a big difference between 
patching an endpoint to a variation of TLS1.2 which is meant to work in 
a ’TLS1.2 designed environment” 
Vs 
patching an endpoint to TLS1.3 in an environment that was ’TLS1.2 
designed environment’

If the organisation that needs to manage a security risk is given a choice of 
1) Patch to TLS-LTS
2) Patch to TLS1.3 

Any risk manager is going to ask the qualification of the implications on both 
and the result will be that 1) will be far less intrusive and risky than 2)

Moreover the bench-test platform that the solution needs to go through to prove 
its production readiness may not be able to support TLS1.3 at all.

Not adopting this draft leaves only one choice to any customer with no 
guarantees that the patching to TLS1.3 will work in its TLS1.2 designed 
end-to-end environment at a manageable time, cost and ‘go to production’ or ‘go 
to market’ time, and risk.

Worse, it could have unanticipated consequences like breaking compliancy to 
regulations, to safety and I can just imagine how it could move the risks from 
bits and bytes to blood and flesh.

My 0.02 Swiss francs

Arnaud Taddei
Global Security Strategist | Enterprise Security Group

mobile: +41 79 506 1129 
Geneva, Switzerland
arnaud.tad...@broadcom.com  | broadcom.com

> On 5 Nov 2024, at 19:48, Nick Harper  wrote:
> 
> I understand the stated goal of this draft to be to provide a way for 
> hard-to-update endpoints to keep using TLS 1.2 in a secure way. The idea of a 
> document that describes how to safely deploy TLS 1.2 sounds like a good idea, 
> e.g. "use only these cipher suites, require EMS and RI, etc". This draft is 
> not that.
> 
> This draft makes changes to the TLS handshake protocol, which undermines the 
> goal of supporting hard-to-update endpoints. The two changes made to the 
> protocol are also addressed by RFC 8446. If endpoints need to be updated to 
> support TLS-LTS, it would make more sense to update them to support TLS 1.3 
> than TLS-LTS.
> 
> The rationale section (3.7) of the draft presents two reasons for using 
> TLS-LTS over TLS 1.3. The first is the slow deployment cadence of a new 
> protocol. LTS requires a change to the protocol and deployment of that new 
> change, no different from 1.3. The second reason is fear of the unknown in 
> 1.3: "TLS 1.3 is an almost entirely new protocol. As such, it rolls back the 
> 20 years of experience that we have with all the things that can go wrong in 
> TLS". The 20 years of all the things that can go wrong in TLS were due to 
> unsound cryptographic decisions. The research and analysis that found those 
> 20 years of issues was applied to the design of 1.3 to avoid making the same 
> mistakes. 1.3 doesn't roll back that experience, and we now have over 8 years 
> of experience with 1.3.
> 
> I do not support adoption of the draft in this format. If the draft made no 
> changes to the TLS 1.2 protocol and were deployable only through 
> configuration changes (e.g. a fixed list of cipher suites and extensions), I 
> would probably support it.
> 
> On Tue, Nov 5, 2024 at 11:02 AM Salz, Rich  > wrote:
>> I strongly support adoption.
>> 
>> I do not understand why anyone would be opposed to the IETF making 
>> deployment recommendations. I can understand why someone might be bothered 
>> by the impliciation that *THIS ONE WAY* is the only way to get long-term 
>> support, especially if it's seen to contradict our encouragement of TLS 1.3. 
>> But that is an editorial issue that can be easily fixed.
>> 
>> I would like to see this adopted, a short change cycle, and then advanced in 
>> the same cluster with our TLS 1.2 is frozen document.
>> 
>> 
>> ___
>> TLS mailing list -- tls@ietf.org 
>> To unsubscribe send an email to tls-le...@ietf.org 
>> 
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org


-- 
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-m

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Watson Ladd]

I'm against adoption. TLS 1.3 has widely been implemented and
depoloyed across embedded devices and has much better analysis. You'd
still need to patch devices for this to be deployable.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Nick Harper]

I understand the stated goal of this draft to be to provide a way for
hard-to-update endpoints to keep using TLS 1.2 in a secure way. The idea of
a document that describes how to safely deploy TLS 1.2 sounds like a good
idea, e.g. "use only these cipher suites, require EMS and RI, etc". This
draft is not that.

This draft makes changes to the TLS handshake protocol, which undermines
the goal of supporting hard-to-update endpoints. The two changes made to
the protocol are also addressed by RFC 8446. If endpoints need to be
updated to support TLS-LTS, it would make more sense to update them to
support TLS 1.3 than TLS-LTS.

The rationale section (3.7) of the draft presents two reasons for using
TLS-LTS over TLS 1.3. The first is the slow deployment cadence of a new
protocol. LTS requires a change to the protocol and deployment of that new
change, no different from 1.3. The second reason is fear of the unknown in
1.3: "TLS 1.3 is an almost entirely new protocol. As such, it rolls back
the 20 years of experience that we have with all the things that can go
wrong in TLS". The 20 years of all the things that can go wrong in TLS were
due to unsound cryptographic decisions. The research and analysis that
found those 20 years of issues was applied to the design of 1.3 to avoid
making the same mistakes. 1.3 doesn't roll back that experience, and we now
have over 8 years of experience with 1.3.

I do not support adoption of the draft in this format. If the draft made no
changes to the TLS 1.2 protocol and were deployable only through
configuration changes (e.g. a fixed list of cipher suites and extensions),
I would probably support it.

On Tue, Nov 5, 2024 at 11:02 AM Salz, Rich  wrote:

> I strongly support adoption.
>
> I do not understand why anyone would be opposed to the IETF making
> deployment recommendations. I can understand why someone might be bothered
> by the impliciation that *THIS ONE WAY* is the only way to get long-term
> support, especially if it's seen to contradict our encouragement of TLS
> 1.3. But that is an editorial issue that can be easily fixed.
>
> I would like to see this adopted, a short change cycle, and then advanced
> in the same cluster with our TLS 1.2 is frozen document.
>
>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Salz, Rich]

I strongly support adoption.

I do not understand why anyone would be opposed to the IETF making deployment 
recommendations. I can understand why someone might be bothered by the 
impliciation that *THIS ONE WAY* is the only way to get long-term support, 
especially if it's seen to contradict our encouragement of TLS 1.3. But that is 
an editorial issue that can be easily fixed.

I would like to see this adopted, a short change cycle, and then advanced in 
the same cluster with our TLS 1.2 is frozen document.


___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Alicja Kario]

I do not support adoption.

On Tuesday, 5 November 2024 17:25:16 CET, Sean Turner wrote:
REQUEST: Let’s not rehash all the context.  It is provided for 
those who might not remember or those that were not around for 
the duration.


CONTEXT: Way back in 2016 after the WG had embarked on 
developing TLS 1.3, Peter Gutmann suggested that another way to 
“fix” TLS was to specify a version of TLS that indicates a 
“known-good config drawn from the maybe 10 extension-RFCs”; see 
[0].  Peter submitted his “TLS 1.2 Update for Long-term 
Support”; see [1]. There was some list discussion; see [2]. 
Peter asked us about adopting the I-D; see [3]. He made changes 
based on that feedback; see [4]. At IETF 98, the WG discussed 
adopting this I-D and the sense of the room was to not adopt the 
I-D; see [5]. Progress on this document was paused while the WG 
worked on TLS 1.3. Once RFC 8447 was published, a code point was 
assigned for the “tls-lts” extensions; see [6] and [7]. Now that 
we are looking to publish Feature Freeze for TLS 1.2 [8][9] we 
want to make sure that the working group sentiment has not 
changed over time so we are running an adoption call for 
TLS-LTS. 

MESSAGE: This message is to judge consensus on whether there is 
support to adopt TLS 1.2 Update for Long-term Support; see [1].  
If you support adoption and are willing to review and contribute 
text, please send a message to the list.  If you do not support 
adoption of this draft, please send a message to the list and 
indicate why.  This call will close on November X, 2024. 


Thanks,
spt

[0] https://mailarchive.ietf.org/arch/msg/tls/Lr7VwcPCjzDJelUTRTIUJf_8-ww/ 
[1] https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/ 
[2] https://mailarchive.ietf.org/arch/msg/tls/r4w75rooy-r8Ky-xXAUoslYTL_U/ 
[3] https://mailarchive.ietf.org/arch/msg/tls/6tBftKBmxYz_wUcq79_zH8yDTQk/ 
[4] https://mailarchive.ietf.org/arch/msg/tls/aw9BOS4HJ9uum0snEZqSuKA4BYw/
[5] https://datatracker.ietf.org/meeting/98/materials/minutes-98-tls-00 
[6] 
https://mailarchive.ietf.org/arch/msg/tls-reg-review/bP84S3tHSG9gAmc45CLTjpiA0z8/
[7] https://mailarchive.ietf.org/arch/msg/tls/xmhnVQTckDmUkoxhx4wx1bfpYXM/ 
   Thanks to Peter because he helped us iron out the

   wrinkles in the tls-reg-review process.
[8] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/ 
[9] https://mailarchive.ietf.org/arch/msg/tls/f62yvLL_4mDEsRzAY46L4QLjakU/ 


--
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Rob Sayre]

On Tue, Nov 5, 2024 at 8:25 AM Sean Turner  wrote:

> REQUEST: Let’s not rehash all the context.  It is provided for those who
> might not remember or those that were not around for the duration.
>
> CONTEXT: Way back in 2016 after the WG had embarked on developing TLS 1.3,
> Peter Gutmann suggested that another way to “fix” TLS was to specify a
> version of TLS that indicates a “known-good config drawn from the maybe 10
> extension-RFCs”; see [0].  Peter submitted his “TLS 1.2 Update for
> Long-term Support”; see [1]. There was some list discussion; see [2]. Peter
> asked us about adopting the I-D; see [3]. He made changes based on that
> feedback; see [4]. At IETF 98, the WG discussed adopting this I-D and the
> sense of the room was to not adopt the I-D; see [5]. Progress on this
> document was paused while the WG worked on TLS 1.3. Once RFC 8447 was
> published, a code point was assigned for the “tls-lts” extensions; see [6]
> and [7]. Now that we are looking to publish Feature Freeze for TLS 1.2
> [8][9] we want to make sure that the working group sentiment has not
> changed over time so we are running an adoption call for TLS-LTS.
>
> MESSAGE: This message is to judge consensus on whether there is support to
> adopt TLS 1.2 Update for Long-term Support; see [1].  If you support
> adoption and are willing to review and contribute text, please send a
> message to the list.  If you do not support adoption of this draft, please
> send a message to the list and indicate why.  This call will close on
> November X, 2024.
>

I do not support adoption, but do not view it as what they call an "end
run" around the WG. So, it would be fine to go to the ISE I think. If it
gets some traction, the WG can take it up again. It's not a permanent
decision.

thanks,
Rob
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[Sean Turner]

> On Nov 5, 2024, at 16:25, Sean Turner  wrote:
> 
> REQUEST: Let’s not rehash all the context.  It is provided for those who 
> might not remember or those that were not around for the duration.
> 
> CONTEXT: Way back in 2016 after the WG had embarked on developing TLS 1.3, 
> Peter Gutmann suggested that another way to “fix” TLS was to specify a 
> version of TLS that indicates a “known-good config drawn from the maybe 10 
> extension-RFCs”; see [0].  Peter submitted his “TLS 1.2 Update for Long-term 
> Support”; see [1]. There was some list discussion; see [2]. Peter asked us 
> about adopting the I-D; see [3]. He made changes based on that feedback; see 
> [4]. At IETF 98, the WG discussed adopting this I-D and the sense of the room 
> was to not adopt the I-D; see [5]. Progress on this document was paused while 
> the WG worked on TLS 1.3. Once RFC 8447 was published, a code point was 
> assigned for the “tls-lts” extensions; see [6] and [7]. Now that we are 
> looking to publish Feature Freeze for TLS 1.2 [8][9] we want to make sure 
> that the working group sentiment has not changed over time so we are running 
> an adoption call for TLS-LTS. 
> 
> MESSAGE: This message is to judge consensus on whether there is support to 
> adopt TLS 1.2 Update for Long-term Support; see [1].  If you support adoption 
> and are willing to review and contribute text, please send a message to the 
> list.  If you do not support adoption of this draft, please send a message to 
> the list and indicate why.  This call will close on November X, 2024. 

Whoops November 26, 2024.

> Thanks,
> spt
> 
> [0] https://mailarchive.ietf.org/arch/msg/tls/Lr7VwcPCjzDJelUTRTIUJf_8-ww/ 
> [1] https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/ 
> [2] https://mailarchive.ietf.org/arch/msg/tls/r4w75rooy-r8Ky-xXAUoslYTL_U/ 
> [3] https://mailarchive.ietf.org/arch/msg/tls/6tBftKBmxYz_wUcq79_zH8yDTQk/ 
> [4] https://mailarchive.ietf.org/arch/msg/tls/aw9BOS4HJ9uum0snEZqSuKA4BYw/
> [5] https://datatracker.ietf.org/meeting/98/materials/minutes-98-tls-00 
> [6] 
> https://mailarchive.ietf.org/arch/msg/tls-reg-review/bP84S3tHSG9gAmc45CLTjpiA0z8/
> [7] https://mailarchive.ietf.org/arch/msg/tls/xmhnVQTckDmUkoxhx4wx1bfpYXM/ 
>   Thanks to Peter because he helped us iron out the
>   wrinkles in the tls-reg-review process.
> [8] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/ 
> [9] https://mailarchive.ietf.org/arch/msg/tls/f62yvLL_4mDEsRzAY46L4QLjakU/

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org