Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Stephen Farrell]

Hiya,

On 12/12/2023 17:08, Russ Housley wrote:

Stephen:

I've been thinking about your point.  Some people want to use RFC
8773 to protect data that is transmitted today and recorded from the
future invention of a quantum computer.  To do this, the handshake
includes the identifier for the external PSK, and an observer can get
tracking data by watching which clients and servers have the same
external PSK.  This tracking data does not need the same long-term
protection as the TLS protected content.  So, the high-level guidance
in the proposed text seems appropriate.  That is, rotation of the
external PSK identity or the use of the Encrypted Client Hello
extension.  I think you are correct, the "with algorithms that a
secure against a CRQC" should be dropped.


Right, I think that means that ECH as-is can be used, but in the face
of a CRQC, ECH as-is won't protect against the leakage about which
John was concerned.

If one is worried about a future CRQC, then using ECH as-is should be
fine and protects for now against that leakage. (One might even add a
bit of text recommending that this extension only be present in the
inner CH whenever ECH is in use?)

Using some future PQ version of ECH can't be done yet, and figuring
out how a PQ-version of ECH would work and not involve too-large a CH
is another day's work.

Cheers,
S.





Russ



On Dec 6, 2023, at 4:21 PM, Stephen Farrell
 wrote:


Hiya,

On 06/12/2023 21:06, Russ Housley wrote:

Stephen: Maybe.  ECH would need to be updated to use PQC
algorithms to get that protection. Ill add that point: Appendix
E.6 of [RFC8446] discusses identity-exposure attacks on PSKs.
Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses 
tracking prevention.  The guidance in these sections remain

relevant. If an external PSK identity is used for multiple
connections, then an observer will generally be able track
clients and/or servers across connections.  The rotation of the
external PSK identity or the use of the Encrypted Client Hello
extension [I-D.ietf-tls-esni] with algorithms that a secure
against a CRQC can mitigate this risk.


That'd be a fairly giant outer client hello though if you include 
real PSK stuff in the inner CH, more or less any PQ hybrid scheme 
and the phoney/GREASE PSK stuff in the outer CH. I dunno if it'd be

feasible to use in practice, which would seem telling in terms of
promotion from experimental. I think someone would need to check 
the numbers and/or maybe figure out if the phoney/GREASE outer PSK 
stuff can be safely omitted in this context, and then write down 
how to do that.


I suspect that could end up with something that'd work ok, but
it'd need some work, and that's in addition to saying how to do the
PQ thing for ECH, which'd involve a number of design decisions I
think, and might in itself be a bit of an experiment.

So I don't think a quick bit of text about ECH solves the problem 
John raised in this context, or, at least, it'd be a non-trivial 
solution, and maybe more that you'd want if starting with with the 
goal in the subject line? (Not trying to be negative, just not at 
all sure.)


Cheers, S.


Russ

On Dec 6, 2023, at 4:00 PM, Stephen Farrell
 wrote:


Hiya,


(3) The privacy considerations already talk about Appendix
E.6 of [RFC8446].  I am please to add a pointer to ECH, but I
do not think that ECH use should not be mandated.


While I'm a fan of ECH, does it actually do the trick here? If
the adversary has a CRQC then we'd need an updated ECH that's
not vulnerable in that scenario, and we don't have that now.
(And it might be hard to get to, given MTU sizes.)

Cheers, S.


I suggest: Appendix E.6 of [RFC8446] discusses
identity-exposure attacks on PSKs.  Also, Appendix C.4 of
[I-D.ietf-tls-rfc8446bis] discusses tracking prevention.  The
guidance in these sections remain relevant. If an external
PSK identity is used for multiple connections, then an
observer will generally be able track clients and/or servers 
across connections.  The rotation of the external PSK

identity or the use of the Encrypted Client Hello extension
[I-D.ietf-tls-esni] can mitigate this risk. Russ
On Dec 6, 2023, at 11:51 AM, John Mattsson 
 wrote: Hi, I

am quite convinced that the security properties are not
worse than a mixture of PSK authentication, PSK key
exchange, (EC)DHE key exchange, and signature
authentication. In some cases, this is very good. You get
the quantum-resistance of the PSK together with the PFS of
ECDHE, and the entity authentication and security policies
of certificates. In other cases, it is not so good as the
reuse of a PSK identifier enables tracking and potentially
identification of both the client and the server. I don’t
think that such a field enabling tracking belongs in modern
TLS, but reuse of a PSK identifier is already in RFC 8446 
so this document does theoretically not make the worst-case

worse. If RFC 8773 is updated. I think the following things
should be updated: - The title and abstract only ta

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

[Watson Ladd]

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

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

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

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

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



-- 
Astra mortemque praestare gradatim

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

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

[Salz, Rich]

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

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

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

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

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

[Rob Sayre]

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

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


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

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

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

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

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

It's starting to resemble Homer's sandwich:


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

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

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

[Ilari Liusvaara]

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

Reading through the document, I noticed the following:

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


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

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

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




-Ilari

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

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Russ Housley]

Christian:

>>> 
>>> Thanks. I am not 100% sure that we actually have an attack against the 
>>> [EC]DH+PSK combination, but I am confident than if the PSK secret is weak, 
>>> the attacker can get to the early data. If only for that, it is prudent to 
>>> use long enough PSK.
>> As stated in draft-ietf-tls-8773bis, some people are interested in using the 
>> external PSK with a certificate to protect against the future invention of a 
>> Cryptographically Relevant Quantum Computer (CRQC).  Others want to use of a 
>> public key with a factory-provisioned secret value for the initial 
>> enrollment of a device in an enterprise network (for example 
>> draft-ietf-emu-bootstrapped-tls).
>> For the security consideration, I suggest an additional paragraph:
>> Implementations must use sufficiently large external PSKs.  For 
>> protection
>> against the future invention of a CRQC, the external PSK needs to be 
>> at
>> least 256 bits.
>> Does that resolve your concern?
> 
> Yes.


I think there is a companion point to be made.  I suggest:

   Implementations must use a ciphersuite that includes a symmetric
   encryption algorithm with sufficiently large keys.  For protection
   against the future invention of a CRQC, the symmetric key needs to be
   at least 256 bits.

   Implementations must use sufficiently large external PSKs.  For
   protection against the future invention of a CRQC, the external PSK
   needs to be at least 256 bits.

Russ

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

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Russ Housley]

Stephen:

I've been thinking about your point.  Some people want to use RFC 8773 to 
protect data that is transmitted today and recorded from the future invention 
of a quantum computer.  To do this, the handshake includes the identifier for 
the external PSK, and an observer can get tracking data by watching which 
clients and servers have the same external PSK.  This tracking data does not 
need the same long-term protection as the TLS protected content.  So, the 
high-level guidance in the proposed text seems appropriate.  That is, rotation 
of the external PSK identity or the use of the Encrypted Client Hello 
extension.  I think you are correct, the "with algorithms that a secure against 
a CRQC" should be dropped.

Russ


> On Dec 6, 2023, at 4:21 PM, Stephen Farrell  wrote:
> 
> 
> Hiya,
> 
> On 06/12/2023 21:06, Russ Housley wrote:
>> Stephen:
>> Maybe.  ECH would need to be updated to use PQC algorithms to get that 
>> protection.
>> Ill add that point:
>>Appendix E.6 of [RFC8446] discusses identity-exposure attacks on
>>PSKs.  Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses
>>tracking prevention.  The guidance in these sections remain relevant.
>>If an external PSK identity is used for multiple connections, then an
>>observer will generally be able track clients and/or servers across
>>connections.  The rotation of the external PSK identity or the use of
>>the Encrypted Client Hello extension [I-D.ietf-tls-esni] with
>>algorithms that a secure against a CRQC can mitigate this risk.
> 
> That'd be a fairly giant outer client hello though if you include
> real PSK stuff in the inner CH, more or less any PQ hybrid scheme
> and the phoney/GREASE PSK stuff in the outer CH. I dunno if it'd
> be feasible to use in practice, which would seem telling in terms
> of promotion from experimental. I think someone would need to check
> the numbers and/or maybe figure out if the phoney/GREASE outer PSK
> stuff can be safely omitted in this context, and then write down
> how to do that.
> 
> I suspect that could end up with something that'd work ok, but it'd
> need some work, and that's in addition to saying how to do the PQ
> thing for ECH, which'd involve a number of design decisions I think,
> and might in itself be a bit of an experiment.
> 
> So I don't think a quick bit of text about ECH solves the problem
> John raised in this context, or, at least, it'd be a non-trivial
> solution, and maybe more that you'd want if starting with with the
> goal in the subject line? (Not trying to be negative, just not at
> all sure.)
> 
> Cheers,
> S.
> 
>> Russ
>>> On Dec 6, 2023, at 4:00 PM, Stephen Farrell  
>>> wrote:
>>> 
>>> 
>>> Hiya,
>>> 
 (3) The privacy considerations already talk about Appendix E.6 of
 [RFC8446].  I am please to add a pointer to ECH, but I do not think
 that ECH use should not be mandated.
>>> 
>>> While I'm a fan of ECH, does it actually do the trick here?
>>> If the adversary has a CRQC then we'd need an updated ECH
>>> that's not vulnerable in that scenario, and we don't have
>>> that now. (And it might be hard to get to, given MTU sizes.)
>>> 
>>> Cheers,
>>> S.
>>> 
 I suggest:
 Appendix E.6 of [RFC8446] discusses identity-exposure attacks on PSKs.  
 Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses tracking 
 prevention.  The guidance in these sections remain
 relevant.
 If an external PSK identity is used for multiple connections, then
 an observer will generally be able track clients and/or servers
 across connections.  The rotation of the external PSK identity or the
 use of the Encrypted Client Hello extension [I-D.ietf-tls-esni] can
 mitigate this risk.
 Russ
> On Dec 6, 2023, at 11:51 AM, John Mattsson
>  wrote:
> Hi,
> I am quite convinced that the security properties are not worse
> than a mixture of PSK authentication, PSK key exchange, (EC)DHE key
> exchange, and signature authentication.
> In some cases, this is very good. You get the quantum-resistance of
> the PSK together with the PFS of ECDHE, and the entity
> authentication and security policies of certificates. In other
> cases, it is not so good as the reuse of a PSK identifier enables
> tracking and potentially identification of both the client and the
> server. I don’t think that such a field enabling tracking belongs
> in modern TLS, but reuse of a PSK identifier is already in RFC 8446
> so this document does theoretically not make the worst-case worse.
> If RFC 8773 is updated. I think the following things should be
> updated: - The title and abstract only talks about PSK
> authentication. The key exchange is likely more important to make
> quantum-resistant than the authentication. I think the title and
> abstract should talk about PSK key exchange. - I think the
> paywalled references should be removed. I think paywalled
> refe

Re: [TLS] ECH: Changes to IANA consideration section

[Sean Turner]

I should also included a link to the revised PR:
https://github.com/tlswg/draft-ietf-tls-esni/pull/597

spt

> On Dec 11, 2023, at 22:01, Sean Turner  wrote:
> 
> I am going to go ahead and forward this. Note that since the “Comments” 
> column isn’t a thing until we get 8447bis through the door the note will 
> follow.
> 
> spt
> 
>> On Dec 6, 2023, at 14:46, Sean Turner  wrote:
>> 
>> Okay a new proposal the ech_outer_extensions registration:
>> - Set "TLS 1.3" column to “CH”
>> - Include the following note in our new “Comments” column [0]: "Only appears 
>> in inner CH."
>> 
>> spt
>> 
>> [0] PRs:
>> https://github.com/tlswg/rfc8447bis/pull/48
>> https://github.com/tlswg/rfc8447bis/pull/49
>> 
>>> On Nov 29, 2023, at 16:09, Stephen Farrell  
>>> wrote:
>>> 
>>> 
>>> Hiya,
>>> 
>>> On 27/11/2023 14:35, Sean Turner wrote:
 Bumping this up in case anybody missed it.
>>> 
>>> 'case it helps, I'm fine with the original mail you sent and any of
>>> "n/a" or "CH" being used rather than "-". If it helps, I've a very
>>> minuscule hint of a preference for "CH" so you can count me as agreeing
>>> with MT.
>>> 
>>> But I won't object to any other thing, 'cause I don't think there's a
>>> perfect answer, and it matters very little, and defining a new thing
>>> like "CHI" just for this seems OTT, but meh, I could even live with
>>> that too.
>>> 
>>> I'd also be fine with this just left to chair/editor discretion FWIW.
>>> While it's good to bring things like that to the list, I don't
>>> think you need to delay based on a small-ish set of responses.
>>> 
>>> Cheers,
>>> S.
>>> 
>>> 
>>> 
 spt
> On Nov 21, 2023, at 21:03, Sean Turner  wrote:
> 
> Hi! I sent over the early allocation request and the IANA folks rightly 
> pointed out two things that need to be added. This email is to make sure 
> we have agreement on the two changes to the registrations in s11.1. If 
> you don’t agree with the values proposed below please let the list know 
> by 1 December 2023.
> 
> 1. The encrypted_client_hello and ech_outer_extensions registrations need 
> to indicate the value for the "DTLS-Only” column. Unless I am mistaken, 
> “N” is the obvious value for both. See 
> https://github.com/tlswg/draft-ietf-tls-esni/pull/584
> 
> 2. The "TLS 1.3” column for ech_outer_extensions registration needs to 
> indicate a value; remember, this column indicates the messages in which 
> the extension may appear.  Currently, it’s “”. “N/A" has been suggested, 
> which makes sense to me considering this extension never directly appears 
> in CH, SH, EE, CT, CR, NST, or HRR extensions field. We can’t use “-“ 
> because that means not used in TLS 1.3. “” is used elsewhere in the 
> registry by only for unassigned and reserved values.  The following PR 
> change “” to “N/A”: https://github.com/tlswg/draft-ietf-tls-esni/pull/59
> 
> Cheers,
> spt
 ___
 TLS mailing list
 TLS@ietf.org
 https://www.ietf.org/mailman/listinfo/tls
>>> 
>> 
> 

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

Re: [TLS] RFC88447bis: additional DE instructions

[Sean Turner]

Hi! Rich $, Martin T, and ekr have all added some thoughts. Anybody else 
have some thoughts?

spt

> On Dec 6, 2023, at 11:20, Sean Turner  wrote:
> 
> Hi! A thread over on the IRTF’s CFRG list, see [0], has resulted in a PR, see 
> [1], that includes additional instructions for the designated experts related 
> to “Expert Review of Current and Potential IETF and IRTF Documents".  Please 
> let us know what you think about the contents of the PR (here or in the PR). 
> Also, please keep messages related to this PR on this list and off the CFRG 
> list.
> 
> Thanks,
> spt
> 
> [0] https://mailarchive.ietf.org/arch/msg/cfrg/QzxwN9hrSGHl0pBdWOhvfZ1UOhM/
> [1] https://github.com/tlswg/rfc8447bis/pull/50
> 

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

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

[Achim Kraus]

Hi Peter,

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

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

best regards
Achim


Am 12.12.23 um 10:09 schrieb Peter Gutmann:

Rob Sayre  writes:


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

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


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


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

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


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

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

[Peter Gutmann]

Loganaden Velvindron  writes:

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

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

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

Peter.

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

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

[Peter Gutmann]

Viktor Dukhovni  writes:

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

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

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

Peter.

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

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

[hannes . tschofenig=40gmx . net]

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

However, there are a few other challenges. 

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

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

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

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

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

Peter,

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


On Tue, 12 Dec 2023 at 05:30, Peter Gutmann  wrote:
>
> Rob Sayre  writes:
>
> >>Given that TLS 1.2 will be around for quite some time
> >Not clear.
>
> Absolutely clear.  I work with stuff with 20-30 year deployment and 
> life cycles.  I'm fairly certain TLS 1.2 will still be around when the 
> WebTLS world is debating the merits of TLS 1.64 vs. TLS 1.65.
>
> (This is also why the TLS-LTS draft was created, BTW).
>
> Peter.
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

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

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

[Peter Gutmann]

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

Peter.




From: TLS  on behalf of Viktor Dukhovni 

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

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

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

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

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

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

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

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

--
Viktor.

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



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

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

[Peter Gutmann]

Rob Sayre  writes:

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

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

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