Subject: Re: [TLS] Flags Extension: why only for TLS 1.3?

From: John Mattsson <[email-masked]>
Date: Thu, 4 Nov 2021 13:11:01 +0000

TLS 1.2 has been obsolete for over three years. Oxford dictionary defines obsolete as "no longer produced or used; out of date." NIST requires support of TLS 1.3 everywhere no later than Jan 2024, which at least in theory means no negotiation of TLS 1.2.

I think IETF, TLS WG, and TLS libraries should spend their time on TLS 1.3 rather than giving the false idea it is ok to stay on TLS 1.2.

John

From: TLS <[email-masked]> on behalf of Hannes Tschofenig <[email-masked]>
Date: Monday, 25 October 2021 at 19:12
To: IETF TLS <[email-masked]>
Subject: [TLS] Flags Extension: why only for TLS 1.3?
Hi all,

why is the flags extension only defined for TLS 1.3?

There is nothing in this extension that prevents us from using it also in TLS 1.2.

Could we make it also available to TLS 1.2?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Sean Turner <[email-masked]>
Date: Thu, 4 Nov 2021 09:27:05 -0400

Hannes,

Sorry I forgot to answer this, but John pretty much answered it for me. The prevailing notion that the WG has been under is that extensions defined are for TLS 1.3. We put the following in the charter to make that clear:

   Changes or additions to older versions of (D)TLS whether
   via extensions or ciphersuites are discouraged and require
   significant justification to be taken on as work items.

So ... do you have a significant justification?

Cheers,
spt

> On Nov 4, 2021, at 09:11, John Mattsson <john.mattsson=[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 4 Nov 2021 13:51:57 +0000

The problem we ran into is the following: We are just publishing the RFCs for the connection IDs for DTLS 1.2 and for DTLS 1.3. For the RRC work we need to define an extension. Using the flags extension makes a lot of sense for TLS 1.3 (to avoid wasting bytes sent over the wire). Should we do something entirely different for DTLS 1.2?

-----Original Message-----
From: Sean Turner <[email-masked]>
Sent: Thursday, November 4, 2021 2:27 PM
To: Hannes Tschofenig <[email-masked]>
Cc: TLS List <[email-masked]>
Subject: Re: [TLS] Flags Extension: why only for TLS 1.3?

Hannes,

Cheers,
spt

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 4 Nov 2021 13:56:42 +0000

The term "obsolete" appears to be used incorrectly when it comes to TLS/DTLS 1.2 used in the IoT environment. It is widely used today and I expect it to be used for a while since (a) there are no security problems with it (when configured correctly), and (b) for many use cases it also offers suitable performance. There is a well-tested open source codebase available for TLS/DTLS 1.2. While I am a big fan of TLS / DTLS 1.3, I would also like to acknowledge the speed at which the market operates.

From: John Mattsson <[email-masked]>
Sent: Thursday, November 4, 2021 2:11 PM
To: Hannes Tschofenig <[email-masked]>; IETF TLS <[email-masked]>
Subject: Re: Flags Extension: why only for TLS 1.3?

John

From: TLS <[email-masked]<mailto:[email-masked]>> on behalf of Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Date: Monday, 25 October 2021 at 19:12
To: IETF TLS <[email-masked]<mailto:[email-masked]>>
Subject: [TLS] Flags Extension: why only for TLS 1.3?
Hi all,

Ciao
Hannes

---

From: David Benjamin <[email-masked]>
Date: Thu, 4 Nov 2021 11:12:59 -0400

While it's true there is still plenty of 1.2 in many environments, defining
a new extension like flags or connection ID won't make it apply to those
connections. Both sides need to deploy new code to implement that
extension. That means we shouldn't be looking at the trailing end of each
environment, but the state of new deployments and where those should go. In
that light, I think it makes sense to focus new protocol development on
1.3. If you have to deploy new TLS software anyway, you should migrate to
1.3.

Indeed it's *because* there is still an existing 1.2 deployment that we
should be judicious with backports. Today, nearly every TLS implementation
needs to implement both 1.2 and 1.3. The ClientHello is cross-version, so
it is not possible for a client to say "I implement xyz extension only at
1.3". That means anyone implementing a backported extension *must* implement
and test it in 1.2, even though it'll be virtually unused. Existing 1.2
peers don't implement it and new peers will use it at 1.3.

On Thu, Nov 4, 2021 at 9:57 AM Hannes Tschofenig <[email-masked]>
wrote:

> The term “obsolete” appears to be used incorrectly when it comes to
> TLS/DTLS 1.2 used in the IoT environment. It is widely used today and I
> expect it to be used for a while since (a) there are no security problems
> with it (when configured correctly), and (b) for many use cases it also
> offers suitable performance. There is a well-tested open source codebase
> available for TLS/DTLS 1.2. While I am a big fan of TLS / DTLS 1.3, I would
> also like to acknowledge the speed at which the market operates.
>
>
>
> *From:* John Mattsson <[email-masked]>
> *Sent:* Thursday, November 4, 2021 2:11 PM
> *To:* Hannes Tschofenig <[email-masked]>; IETF TLS <
> [email-masked]>
> *Subject:* Re: Flags Extension: why only for TLS 1.3?
>
>
>
> TLS 1.2 has been obsolete for over three years. Oxford dictionary defines
> obsolete as "no longer produced or used; out of date." NIST requires
> support of TLS 1.3 everywhere no later than Jan 2024, which at least in
> theory means no negotiation of TLS 1.2.
>
>
>
> I think IETF, TLS WG, and TLS libraries should spend their time on TLS
> 1.3 rather than giving the false idea it is ok to stay on TLS 1.2.
>
>
>
> John
>
>
>
> *From: *TLS <[email-masked]> on behalf of Hannes Tschofenig <
> [email-masked]>
> *Date: *Monday, 25 October 2021 at 19:12
> *To: *IETF TLS <[email-masked]>
> *Subject: *[TLS] Flags Extension: why only for TLS 1.3?
>
> Hi all,
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 4 Nov 2021 15:57:01 +0000

Hi David,

  *   While it's true there is still plenty of 1.2 in many environments, defining a new extension like flags or connection ID won't make it apply to those connections. Both sides need to deploy new code to implement that extension. That means we shouldn't be looking at the trailing end of each environment, but the state of new deployments and where those should go. In that light, I think it makes sense to focus new protocol development on 1.3. If you have to deploy new TLS software anyway, you should migrate to 1.3.

This is just my experience: our partners are interested in moving to TLS 1.3. That’s great. There is still a lot of deployment based on 1.2. This deployment needs to be maintained. Companies have deployed the CID extension already and will apply software updates. Updating the code to add a feature, a bugfix and alike is one thing. Switching out the security stack altogether is not a minor thing.

  *   Indeed it's because there is still an existing 1.2 deployment that we should be judicious with backports. Today, nearly every TLS implementation needs to implement both 1.2 and 1.3. The ClientHello is cross-version, so it is not possible for a client to say "I implement xyz extension only at 1.3". That means anyone implementing a backported extension must implement and test it in 1.2, even though it'll be virtually unused. Existing 1.2 peers don't implement it and new peers will use it at 1.3.

In the IoT space, the device have constraints. They are not implementing a dual stack 1.2 / 1.3 version for Cortex M class devices (at least in almost all cases).

If I have to define an extension for use with the ClientHello in DTLS 1.2 and a different one (based on flags) in DTLS 1.3 then this would not make my life any easier.

Ciao
Hannes

On Thu, Nov 4, 2021 at 9:57 AM Hannes Tschofenig <[email-masked]<mailto:[email-masked]>> wrote:
The term “obsolete” appears to be used incorrectly when it comes to TLS/DTLS 1.2 used in the IoT environment. It is widely used today and I expect it to be used for a while since (a) there are no security problems with it (when configured correctly), and (b) for many use cases it also offers suitable performance. There is a well-tested open source codebase available for TLS/DTLS 1.2. While I am a big fan of TLS / DTLS 1.3, I would also like to acknowledge the speed at which the market operates.

From: John Mattsson <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, November 4, 2021 2:11 PM
To: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; IETF TLS <[email-masked]<mailto:[email-masked]>>
Subject: Re: Flags Extension: why only for TLS 1.3?

John

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Achim Kraus <[email-masked]>
Date: Thu, 4 Nov 2021 19:05:29 +0100

Hi Sean,

I hope, the answer of Hannes counts as "significant justification".

Most of the discussion and arguments are about TLS 1.2 and 1.3.

Just to be clear:
RRC will only apply to DTLS, 1.2 and 1.3. There is no usage for TLS.
And for RRC, Hannes and Thomas wants to use the "Flags Extension".

I'm not sure, how fast DTLS 1.2 deployments will be moved to DTLS 1.3.
But I'm pretty sure, that DTLS 1.2 with Connection ID will make many
NB-IoT solutions possible, and RRC will help to defend that against
attacks.

best regards
Achim Kraus
Eclipse/Californium
(Currently DTLS 1.2 only ;-) )

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Nov 2021 13:34:16 -0700

FWIW, while I don't think we should be doing much enhancement of (D)TLS
1.2, I also don't think it makes sense not to allow enhancements to 1.3 to
be used with 1.2 where that makes sense, as it seems to here.

-Ekr

On Thu, Nov 4, 2021 at 11:05 AM Achim Kraus <[email-masked]> wrote:

> > Sorry I forgot to answer this, but John pretty much answered it for me.
> The prevailing notion that the WG has been under is that extensions defined
> are for TLS 1.3. We put the following in the charter to make that clear:
> >
> >> TLS 1.2 has been obsolete for over three years. Oxford dictionary
> defines obsolete as "no longer produced or used; out of date." NIST
> requires support of TLS 1.3 everywhere no later than Jan 2024, which at
> least in theory means no negotiation of TLS 1.2.
> >>

---

From: "Filippo Valsorda" <[email-masked]>
Date: Thu, 04 Nov 2021 20:46:54 -0400

2021-11-04 11:12 GMT-04:00 David Benjamin <[email-masked]>:
> Indeed it's *because* there is still an existing 1.2 deployment that we should be judicious with backports. Today, nearly every TLS implementation needs to implement both 1.2 and 1.3. The ClientHello is cross-version, so it is not possible for a client to say "I implement xyz extension only at 1.3". That means anyone implementing a backported extension *must* implement and test it in 1.2, even though it'll be virtually unused. Existing 1.2 peers don't implement it and new peers will use it at 1.3.

What David mentions here resonates and is worth underscoring. Specifying an extension for both TLS 1.2 and TLS 1.3 forces almost every stack to support it at both versions. We don't get to choose "no, we only implement new stuff in TLS 1.3", which as far as Go is concerned, is the policy we want.

I understand that IoT devices are not running dual stacks, but that's not the point. This is an ecosystem cost analysis. If the extension is defined at both TLS 1.2 and TLS 1.3, all dual stacks out there will need to support it at both versions.

I think the condition in the charter that Sean mentioned is good, and should be abided. If an extension is about TLS 1.2 compatibility or transition, or if it's important not to fracture the ecosystem, it might be worth backporting; if it's just convenient for stacks that have not updated yet, it should not.

---

From: Thomas Fossati <[email-masked]>
Date: Fri, 5 Nov 2021 07:07:44 +0000

hi John,

> 1.3 rather than giving the false idea it is ok to stay on TLS 1.2.

Whilst I agree on the general sentiment, let me point out that the specific
extension we wanted to register (RRC) would be DTLS-only.

And while deprecating TLS 1.2 is certainly OK since 8446 has been around
for 3+ years, the deprecation of DTLS 1.2 would seem a tad premature absent
a published RFC for 1.3 (*)

cheers!

(*) This is going to change soon, but it'll take time for implementations
to catch up (**)

(**) IoT is a vastly different space compared to telco and web.  It is very
fragmented with no real incumbents that could orchestrate a quick
switchover.  Also, because of the heterogeneity of platforms there is a
very high number of purpose built stacks.  So we need to be a bit more
patient (***)

(***) Nothing, just checking if you are still following me in this meander
of recursive footnotes ;-)

-- 
Thomas