Re: [TLS] multi-identity support in RFC 8446

[Chuck Lever III]

Hello Andrei -

> On Mar 2, 2023, at 12:47 PM, Andrei Popov  wrote:
> 
>> I don't have details, but the NVMe/TCP specification suggests that it can 
>> make use of multiple PSK identities during a TLS handshake.
> From my read of NVMe spec, it's one PSK/identity per TLS connection:
> 
> "8.13.5.9 Generated PSK for TLS
> When used with a non-NULL DH exchange, the DH-HMAC-CHAP protocol is able to 
> generate a session
> key KS used to generate *a pre-shared key (PSK)* to establish a secure 
> channel session with the TLS protocol
> between host and controller. A TLS session is concatenated to an 
> authentication transaction when the
> SC_C indication is set to 01h in the AUTH_Negotiate message. A TLS session 
> should not be concatenated
> to an authentication transaction if the involved host and controller are 
> administratively configured with *a
> PSK* for use with each other. In this case, host and controller should just 
> establish a TLS session based on
> the configured PSK."
> 
> From the above, it looks like NVMe specifies two options: 
> 1.Generating PSK based on a Diffie-Hellman key exchange (as part of 
> DH-HMAC-CHAP protocol).
> 2.Admin configuring host and controller with a PSK.
> In both cases, it seems that there is one PSK/identity per host-controller 
> connection.
> 
> Please correct me if I mis-interpret the NVMe spec,

This is what I've been told:

NVMe-TCP spec v1.0a section 3.6.1.3 (TLS PSK and PSK Identity Derivation):

> In TLS 1.3 each PSK is identified by the client using a PSK
> identity. Each PSK is also associated with one hash function
> that shall be the same as the hash function of the selected
> ciphersuite. For example, the cipher suites TLS_AES_128_GCM_SHA256
> and TLS_AES_256_GCM_SHA384 use the SHA-256 and SHA-384 hash
> functions respectively. A TLS client that offers both cipher
> suites shall offer two PSKs with different identities, different
> hash functions, and different key material.

In addition to that, each cipher suite might be used for
either generated or retained PSKs. This results in a total
of 4 possible PSK identities, each with different keying
material.

As per TLS 1.3 it's then the servers responsibility to pick
one of the presented identities, and return that one with the
ServerHello response. The PSK of the returned identity will
then be used for the connection. Thus there is only one
PSK/identity per connection. It's only the ClientHello which
can/might carry several PSK identities (as outlined in RFC 8446).

Note also: there is a provision in the NVMe spec to send only
a single PSK identity with ClientHello:

> A TLS 1.3 client implementation that only supports sending
> a single PSK identity during connection setup may be required
> to connect multiple times in order to negotiate cipher suites
> with different hash functions.


--
Chuck Lever


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

Re: [TLS] Question on draft-ietf-tls-deprecate-obsolete-kex-01.txt

[Nimrod Aviram]

Hi Eric and Everyone, draft coauthor here.

Appendix C lists "DHE Cipher Suites Refered to by This Document", not ones
which are deprecated.
The intention of the current text is to permit fully ephemeral DHE over a
finite field (FFDHE) with sufficient group size.

However, we also have an unresolved consensus call regarding whether/to
what extent to permit FFDHE when this document (hopefully) becomes an
official RFC:
https://mailarchive.ietf.org/arch/msg/tls/iZGV0kKHfbV5MrO-owB8mFwfffw/
so at any rate, the current text around FFDHE is mostly a placeholder.
I do hope to present at the upcoming WG meeting and resolve this issue,
which should be the last one (famous last words, I know).

Happy to answer further questions, or generally get a discussion going on
here before the meeting.

best,
Nimrod




On Thu, 2 Mar 2023 at 23:19, Eric Rescorla  wrote:

> Hi folks,
>
> I was just reading draft-ietf-tls-deprecate-obsolete-kex-01.txt
> and the combination of Section 3 and Appendix C is confusing
> to me.
>
> Specifically, the text says:
>
>Clients and servers MAY offer fully ephemeral FFDHE cipher suites in
>TLS 1.2 connections under the following conditions:
>
>1.  Clients and servers MUST NOT reuse ephemeral DHE public keys
>across TLS connections for all existing (and future) TLS
>versions.  Doing so invalidates forward secrecy properties of
>these connections.  For DHE, such reuse may also lead to
>vulnerabilities such as those used in the [Raccoon] attack.  See
>Section 6 for related discussion.
>
>2.  The group size is at least 2048 bits.
>
>...
>
>All the cipher suites that do not meet the above requirements are
>listed in the table in Appendix C.
>
>
> And then Appendix C lists, for instance:
>
>TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
>
> Which as I understand it, can be used with the above requirements
> as long as you use a suitable group, so this makes me think maybe
> I don't understand the text. What cipher suites is this intended
> to permit in TLS 1.2?
>
> -Ekr
>
>
>
> ___
> 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] Question on draft-ietf-tls-deprecate-obsolete-kex-01.txt

[Eric Rescorla]

On Fri, Mar 3, 2023 at 9:21 AM Nimrod Aviram 
wrote:

> Hi Eric and Everyone, draft coauthor here.
>
> Appendix C lists "DHE Cipher Suites Refered to by This Document", not ones
> which are deprecated.
>
The intention of the current text is to permit fully ephemeral DHE over a
> finite field (FFDHE) with sufficient group size.
>

That's what I got from the title of Appendix CA, but then what does this
text
mean:

"All the cipher suites that do not meet the above requirements are
 listed in the table in Appendix C."

Because, as you say, some of the suites in C meet this requirement.



>
> However, we also have an unresolved consensus call regarding whether/to
> what extent to permit FFDHE when this document (hopefully) becomes an
> official RFC:
> https://mailarchive.ietf.org/arch/msg/tls/iZGV0kKHfbV5MrO-owB8mFwfffw/
> so at any rate, the current text around FFDHE is mostly a placeholder.
> I do hope to present at the upcoming WG meeting and resolve this issue,
> which should be the last one (famous last words, I know).
>
> Happy to answer further questions, or generally get a discussion going on
> here before the meeting.
>

OK, so we don't need to spend too much time on this, but I'd still like to
understand
the intent :)

-Ekr


>
> best,
> Nimrod
>
>
>
>
> On Thu, 2 Mar 2023 at 23:19, Eric Rescorla  wrote:
>
>> Hi folks,
>>
>> I was just reading draft-ietf-tls-deprecate-obsolete-kex-01.txt
>> and the combination of Section 3 and Appendix C is confusing
>> to me.
>>
>> Specifically, the text says:
>>
>>Clients and servers MAY offer fully ephemeral FFDHE cipher suites in
>>TLS 1.2 connections under the following conditions:
>>
>>1.  Clients and servers MUST NOT reuse ephemeral DHE public keys
>>across TLS connections for all existing (and future) TLS
>>versions.  Doing so invalidates forward secrecy properties of
>>these connections.  For DHE, such reuse may also lead to
>>vulnerabilities such as those used in the [Raccoon] attack.  See
>>Section 6 for related discussion.
>>
>>2.  The group size is at least 2048 bits.
>>
>>...
>>
>>All the cipher suites that do not meet the above requirements are
>>listed in the table in Appendix C.
>>
>>
>> And then Appendix C lists, for instance:
>>
>>TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
>>
>> Which as I understand it, can be used with the above requirements
>> as long as you use a suitable group, so this makes me think maybe
>> I don't understand the text. What cipher suites is this intended
>> to permit in TLS 1.2?
>>
>> -Ekr
>>
>>
>>
>> ___
>> 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] How are we planning to deprecate TLS 1.2?

[Nimrod Aviram]

Hi Everyone,

We’ve recently had a brief side discussion around the issue of letting
vendors (or operators) know when something is expected to be deprecated:
https://mailarchive.ietf.org/arch/msg/tls/Djk35kp5P5Z1WfmN8_OJj_eYRLo/

Currently, there is no expected deprecation timeline for any specific
primitive or protocol version. As one example, it seems like we plan to
deprecate RSA key exchange in TLS 1.2 soon (as part of
draft-ietf-tls-deprecate-obsolete-kex). However, so far we did not
explicitly communicate this to vendors, and it seems like vendors either
have to follow the mailing list and deduce the likelihood of an upcoming
deprecation, or face a deprecation RFC at some random point in time (from
their point of view).

And whatever the specifics of RSA key exchange deprecation, this will
likely not be the last time we deprecate something :-)

Specifically, we will have to decide when/if to deprecate version 1.2 of
TLS within, say, the next 20 years.

One possible solution is to publish “expected deprecation timeline”
documents:
Let’s fix some timeframe which “is enough for everyone to upgrade at least
once” (famous last words, I know). I think of this timeframe as 3 or 5
years, but it could as well be 8 or 10 years, and this solution would still
be viable; let’s denote the number of years as X. So, an “expected
deprecation timeline” document could specify that within X years,
implementations MUST support TLS 1.3, and within 2X years, implementations
MUST NOT support TLS 1.2. (If X=8 years, then we specify that by 2031
implementations MUST support TLS 1.3, and by 2039 implementations MUST NOT
support TLS 1.2.) This would clarify the WG’s expectations to vendors, and
would save the WG valuable time discussing whether enough implementations
in the field support the new protocol/primitive.

Is there interest here in such a solution?

Credit where it’s due: This is based on an idea I heard from Dan Bernstein
- thanks Dan.

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

Re: [TLS] How are we planning to deprecate TLS 1.2?

[Eric Rescorla]

Nimrod,

Thanks for bringing this up. I don't think we really have had much of a
discussion.

I *do* think we should be thinking about deprecating TLS 1.2 at some point,
not so much because
it is bad (though of course we believe TLS 1.3 is better)  but because it's
better to just have
one thing that we work on and not have to reason about/work on TLS 1.2. And
of course, we really
don't want to have to do major work on TLS 1.2, e.g. for Post-Quantum.

I don't have strong feelings about the timeline.

-Ekr




On Fri, Mar 3, 2023 at 10:18 AM Nimrod Aviram 
wrote:

> Hi Everyone,
>
> We’ve recently had a brief side discussion around the issue of letting
> vendors (or operators) know when something is expected to be deprecated:
> https://mailarchive.ietf.org/arch/msg/tls/Djk35kp5P5Z1WfmN8_OJj_eYRLo/
>
> Currently, there is no expected deprecation timeline for any specific
> primitive or protocol version. As one example, it seems like we plan to
> deprecate RSA key exchange in TLS 1.2 soon (as part of
> draft-ietf-tls-deprecate-obsolete-kex). However, so far we did not
> explicitly communicate this to vendors, and it seems like vendors either
> have to follow the mailing list and deduce the likelihood of an upcoming
> deprecation, or face a deprecation RFC at some random point in time (from
> their point of view).
>
> And whatever the specifics of RSA key exchange deprecation, this will
> likely not be the last time we deprecate something :-)
>
> Specifically, we will have to decide when/if to deprecate version 1.2 of
> TLS within, say, the next 20 years.
>
> One possible solution is to publish “expected deprecation timeline”
> documents:
> Let’s fix some timeframe which “is enough for everyone to upgrade at least
> once” (famous last words, I know). I think of this timeframe as 3 or 5
> years, but it could as well be 8 or 10 years, and this solution would still
> be viable; let’s denote the number of years as X. So, an “expected
> deprecation timeline” document could specify that within X years,
> implementations MUST support TLS 1.3, and within 2X years, implementations
> MUST NOT support TLS 1.2. (If X=8 years, then we specify that by 2031
> implementations MUST support TLS 1.3, and by 2039 implementations MUST NOT
> support TLS 1.2.) This would clarify the WG’s expectations to vendors, and
> would save the WG valuable time discussing whether enough implementations
> in the field support the new protocol/primitive.
>
> Is there interest here in such a solution?
>
> Credit where it’s due: This is based on an idea I heard from Dan Bernstein
> - thanks Dan.
>
> Best,
> Nimrod
>
> ___
> 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] How are we planning to deprecate TLS 1.2?

[Kenneth Vaughn]

+1 on the idea, but I am not convinced that the proposed process is sufficient 
(and/or terms are not adequately clear). 

It seems to me that the time "for everyone to upgrade" will be dependent upon 
market factors related to the technology being replaced as well as with the 
severeness of the problem and the nature of the environment. In particular, I 
would generally expect that there might be different timelines for:
1. The new version being supported by newly purchased implementations
2. The new version being supported by all high-end equipment (e.g., servers) 
within data centers (i.e., upgrading things that are easy to upgrade)
3. The new version being supported by all equipment within data centers
4. The new version being supported by all high-end equipment installed in the 
field or mobile devices
5. The new version being supported by all field or mobile devices (e.g., even 
IoT sensors that use the technology)
6. The old version no longer being enabled

Perhaps part of this was the concept of 1X and 2X because it is unclear why we 
would allow the use of the old technology if everyone supports the new 
technology. In any case, I think X is likely to be a variable that has to be 
established by consensus for each version of each technology (e.g., protocol). 
However, it might be possible to define a single variable per version while 
having a standardized formula that customizes the timeline for each of the 
above, e.g., (based on the item numbers above)
1. 1X
2. 1.5X
3. 1.75X
4. 1.5X
5. 2X
6. 2X

I would assume that all of this would be presented as guidance as I don't think 
we can dictate what people actually market. This is why I listed item 6 as 
"enabled" implying that the market could still sell the old technology, but the 
goal is to make sure it is not being used. 

Regards,
Ken Vaughn

Trevilon LLC
1060 S Hwy 107
Del Rio, TN 37727
+1-571-331-5670 cell
kvau...@trevilon.com
www.trevilon.com

> On Mar 3, 2023, at 1:17 PM, Nimrod Aviram  wrote:
> 
> Hi Everyone,
> 
> We’ve recently had a brief side discussion around the issue of letting 
> vendors (or operators) know when something is expected to be deprecated:
> https://mailarchive.ietf.org/arch/msg/tls/Djk35kp5P5Z1WfmN8_OJj_eYRLo/
>  
> Currently, there is no expected deprecation timeline for any specific 
> primitive or protocol version. As one example, it seems like we plan to 
> deprecate RSA key exchange in TLS 1.2 soon (as part of 
> draft-ietf-tls-deprecate-obsolete-kex). However, so far we did not explicitly 
> communicate this to vendors, and it seems like vendors either have to follow 
> the mailing list and deduce the likelihood of an upcoming deprecation, or 
> face a deprecation RFC at some random point in time (from their point of 
> view).
> 
> And whatever the specifics of RSA key exchange deprecation, this will likely 
> not be the last time we deprecate something :-)
> 
> Specifically, we will have to decide when/if to deprecate version 1.2 of TLS 
> within, say, the next 20 years.
> 
> One possible solution is to publish “expected deprecation timeline” documents:
> Let’s fix some timeframe which “is enough for everyone to upgrade at least 
> once” (famous last words, I know). I think of this timeframe as 3 or 5 years, 
> but it could as well be 8 or 10 years, and this solution would still be 
> viable; let’s denote the number of years as X. So, an “expected deprecation 
> timeline” document could specify that within X years, implementations MUST 
> support TLS 1.3, and within 2X years, implementations MUST NOT support TLS 
> 1.2. (If X=8 years, then we specify that by 2031 implementations MUST support 
> TLS 1.3, and by 2039 implementations MUST NOT support TLS 1.2.) This would 
> clarify the WG’s expectations to vendors, and would save the WG valuable time 
> discussing whether enough implementations in the field support the new 
> protocol/primitive.
> 
> Is there interest here in such a solution?
> 
> Credit where it’s due: This is based on an idea I heard from Dan Bernstein - 
> thanks Dan.
> 
> Best,
> Nimrod
> 
> ___
> 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] How are we planning to deprecate TLS 1.2?

[Sean Turner]

just want to point of out that at least in the IETF that RFC 9325 [1] was 
recently published.

spt

[1] https://datatracker.ietf.org/doc/rfc9325/

> On Mar 3, 2023, at 13:40, Eric Rescorla  wrote:
> 
> Nimrod,
> 
> Thanks for bringing this up. I don't think we really have had much of a 
> discussion.
> 
> I *do* think we should be thinking about deprecating TLS 1.2 at some point, 
> not so much because
> it is bad (though of course we believe TLS 1.3 is better)  but because it's 
> better to just have
> one thing that we work on and not have to reason about/work on TLS 1.2. And 
> of course, we really
> don't want to have to do major work on TLS 1.2, e.g. for Post-Quantum.
> 
> I don't have strong feelings about the timeline.
> 
> -Ekr
> 
> 
> 
> 
> On Fri, Mar 3, 2023 at 10:18 AM Nimrod Aviram  wrote:
> Hi Everyone,
> 
> We’ve recently had a brief side discussion around the issue of letting 
> vendors (or operators) know when something is expected to be deprecated:
> https://mailarchive.ietf.org/arch/msg/tls/Djk35kp5P5Z1WfmN8_OJj_eYRLo/
> 
> Currently, there is no expected deprecation timeline for any specific 
> primitive or protocol version. As one example, it seems like we plan to 
> deprecate RSA key exchange in TLS 1.2 soon (as part of 
> draft-ietf-tls-deprecate-obsolete-kex). However, so far we did not explicitly 
> communicate this to vendors, and it seems like vendors either have to follow 
> the mailing list and deduce the likelihood of an upcoming deprecation, or 
> face a deprecation RFC at some random point in time (from their point of 
> view).
> 
> And whatever the specifics of RSA key exchange deprecation, this will likely 
> not be the last time we deprecate something :-)
> 
> Specifically, we will have to decide when/if to deprecate version 1.2 of TLS 
> within, say, the next 20 years.
> 
> One possible solution is to publish “expected deprecation timeline” documents:
> Let’s fix some timeframe which “is enough for everyone to upgrade at least 
> once” (famous last words, I know). I think of this timeframe as 3 or 5 years, 
> but it could as well be 8 or 10 years, and this solution would still be 
> viable; let’s denote the number of years as X. So, an “expected deprecation 
> timeline” document could specify that within X years, implementations MUST 
> support TLS 1.3, and within 2X years, implementations MUST NOT support TLS 
> 1.2. (If X=8 years, then we specify that by 2031 implementations MUST support 
> TLS 1.3, and by 2039 implementations MUST NOT support TLS 1.2.) This would 
> clarify the WG’s expectations to vendors, and would save the WG valuable time 
> discussing whether enough implementations in the field support the new 
> protocol/primitive.
> 
> Is there interest here in such a solution?
> 
> Credit where it’s due: This is based on an idea I heard from Dan Bernstein - 
> thanks Dan.
> 
> Best,
> Nimrod
> 
> ___
> 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] How are we planning to deprecate TLS 1.2?

[Bas Westerbaan]

>
> And of course, we really
> don't want to have to do major work on TLS 1.2, e.g. for Post-Quantum.
>

More to the point, I'd say the post-quantum transition is the natural
moment to move from ≤1.2 to 1.3.

(TLS 1.2 and earlier are vulnerable to PQ -> classical downgrades during
the transition because of CurveSwap like attacks.)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] How are we planning to deprecate TLS 1.2?

[Ilari Liusvaara]

On Fri, Mar 03, 2023 at 09:37:48PM +0100, Bas Westerbaan wrote:
> >
> > And of course, we really
> > don't want to have to do major work on TLS 1.2, e.g. for Post-Quantum.
> >
> 
> More to the point, I'd say the post-quantum transition is the
> natural moment to move from ≤1.2 to 1.3.

Agreed.
 
> (TLS 1.2 and earlier are vulnerable to PQ -> classical downgrades
> during the transition because of CurveSwap like attacks.)

I would say that much more severe problem is that TLS 1.2 group shares
are too small and the rest is not even close to how KEM operates. So
one would need to pretty much redefine the entiere key exchange, which
is not a good idea.

Whereas TLS 1.3 group shares can be large enough, offering the trivial
extension to post-quantum.



-Ilari

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

Re: [TLS] How are we planning to deprecate TLS 1.2?

[Viktor Dukhovni]

On Fri, Mar 03, 2023 at 08:17:55PM +0200, Nimrod Aviram wrote:

> Specifically, we will have to decide when/if to deprecate version 1.2 of
> TLS within, say, the next 20 years.

20 years is a long time.  We can only reason about shorter timelines.
In the next ~5 years, I don't yet see a defensible reason to deprecate
TLS 1.2.

There are still to this day supported LTS enterprise operating systems
that support only TLS 1.2.  Yes, they're nearing EOL, but are not there
yet.

Also, TLS 1.3 is not a simple evolutionary update, it is a major new
protocol, be it one that largely manages to masquerades as TLS 1.2 to
middleboxes, and supports version negotiation with TLS 1.2 peers.

Migration to TLS 1.3 is not always straightforward, and, especially in
terms of resumption behaviour, troubleshooting (largely encrypted
handshakes) and maturity of supporting software in specialised
application sectors, TLS 1.3 is still too young to talk about imminent
deprecation of TLS 1.2.

Yes, once TLS 1.3 is closer to 20 years old, we'll know whether TLS 1.2
can or should be retired, but until such time, TLS 1.2 is likely to
still be with us (embedded in home routers, printers, refrigerators,
...).

Even among (presumably security minded) SMTP server operators who've
deployed DANE, ~10% negotiate TLS 1.2.  The numbers are likely higher in
the broader SMTP ecosystem.  DANE survey SMTP endpoint counts by TLS
version:

  27,985 -  TLS 1.3
   2,927 -  TLS 1.2
   5 -  TLS 1.0

-- 
Viktor.

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

Re: [TLS] How are we planning to deprecate TLS 1.2?

[Rob Sayre]

On Fri, Mar 3, 2023 at 11:25 AM Sean Turner  wrote:

> just want to point of out that at least in the IETF that RFC 9325 [1] was
> recently published.
>

Right. A salient sentence here: "Therefore, this document replaces
[RFC7525], with an explicit goal to encourage migration of most uses of TLS
1.2 to TLS 1.3."

Also, many TLS libraries have started to disentangle TLS 1.2 from TLS 1.3
code. The one I use most often is Rustls, and there's a build flag for this:
https://github.com/rustls/rustls/blob/25bc1b3ecd559ea70c6ae8a83533d430dd67db35/rustls/Cargo.toml#L24

I ship TLS 1.3-only all the time. I wouldn't do that for a really popular
website just yet, but it's usually fine.

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

Re: [TLS] How are we planning to deprecate TLS 1.2?

[Peter Gutmann]

Viktor Dukhovni  writes:

>Yes, once TLS 1.3 is closer to 20 years old, we'll know whether TLS 1.2 can
>or should be retired, but until such time, TLS 1.2 is likely to still be with
>us (embedded in home routers, printers, refrigerators, ...).

Another thing we need a lot more time to find out is whether, like HTTP > 1.1,
TLS 1.3 has forked TLS.  For HTTP there'll perpetually be two lines going
forward, HTTP  for web browsers and HTTP 1.1 for everything that
isn't a web browser.  For embedded/SCADA TLS use you've now got a complete
second protocol stack to fit into your limited firmware space, it offers no
real security advantages over (non-buggy) TLS 1.2, and its performance is
often much worse than TLS 1.2 (yeah, citation needed for that, I'm working on
writing up some of this), so that some users who did try TLS 1.3 quickly
reverted back to 1.2.

So I'd say wait 20 years or so to see where things are going, and look across
at HTTP  vs. HTTP 1.1 for a worked example.

Peter.

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

[TLS] tls - Requested session has been scheduled for IETF 116

["IETF Secretariat"]

Dear Sean Turner,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 


tls Session 1 (2:00 requested)
Tuesday, 28 March 2023, Session II 0400-0600
Room Name: G401-G402 size: 225
-


iCalendar: https://datatracker.ietf.org/meeting/116/sessions/tls.ics

Request Information:


-
Working Group Name: Transport Layer Security
Area Name: Security Area
Session Requester: Sean Turner


Number of Sessions: 1
Length of Session(s): 
Number of Attendees: 120
Conflicts to Avoid: 

   


Participants who must be present:
  Christopher A. Wood
  Eric Rescorla
  Joseph A. Salowey
  Paul Wouters
  Sean Turner

Resources Requested:

Special Requests:
  
-


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

Re: [TLS] How are we planning to deprecate TLS 1.2?

[Watson Ladd]

On Fri, Mar 3, 2023, 1:50 PM Viktor Dukhovni  wrote:
>
> On Fri, Mar 03, 2023 at 08:17:55PM +0200, Nimrod Aviram wrote:
>
> > Specifically, we will have to decide when/if to deprecate version 1.2 of
> > TLS within, say, the next 20 years.
>
> 20 years is a long time.  We can only reason about shorter timelines.
> In the next ~5 years, I don't yet see a defensible reason to deprecate
> TLS 1.2.


20 years from today we'll be dealing with products shipped out today.
Doesn't it make sense to start saying TLS 1.2 will sunset at some day?
The other aspect is with new standardization. Do we want TLS 1.3 only
drafts for post quantum or do we need to go back and deal with TLS
1.2? Nobody is expecting this to be overnight.

Sincerely,
Watson
>
> --
> 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] How are we planning to deprecate TLS 1.2?

[Rob Sayre]

On Fri, Mar 3, 2023 at 2:54 PM Peter Gutmann 
wrote:

> Another thing we need a lot more time to find out is whether, like HTTP >
> 1.1,
> TLS 1.3 has forked TLS.  For HTTP there'll perpetually be two lines going
> forward, HTTP  for web browsers and HTTP 1.1 for everything
> that
> isn't a web browser.
>

I don't think this characterization is quite right. Operating systems and
standard libraries often supply this code. The application code handling a
GET/POST is often unconcerned with the underlying HTTP version. One example
is here:

https://developer.apple.com/documentation/technotes/tn3102-http3-in-your-app

More libraries here:

https://en.wikipedia.org/wiki/HTTP/3#Libraries

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

Re: [TLS] Packet number encryption negotiation

[Lanlan Pan]

Boris Pismenny  于2023年3月2日周四 18:43写道：

>
> On Tue, Feb 28, 2023 at 2:18 PM Lanlan Pan  wrote:
>
>> Personally I think, the negotiation may cause the downgrade security
>> risk, making PNE not actually work for privacy protection.
>> The hardware acceleration can support both PNE and plaintext packet
>> number.
>> Maybe we can consider assigning a new port, just for plaintext packet
>> number's QUIC/DTLS ?
>> such as :
>> port 80: plain text, http
>> port 443: QUIC with PNE/TLS, by default.
>> port 886: QUIC with plaintext packet number, only used on specific
>> environments.
>> port 4433: DTLS with PNE, by default.
>> port 8866: DTLS with plaintext packet number, only used on specific
>> environments.
>>
>>>
>>>
> Thanks for proposing this.
>
> Multiplexing at the transport layer would work, and I don't mind going
> that route.
> But I'm not sure if that's so much different from negotiating in-band
> given that
> the default configuration is to disallow plaintext packet numbers.
>

Thanks Boris.
My concern is, negotiating in-band, may make us hard to prevent the abuse
of "NO PNE" configuration.


> Moreover, DTLS1.2 and DTLS1.3 use the same port while providing different
> guarantees related to PNE, so using this logic suggests that DTLS1.2 should
> run on a different port too?!
>

The logic is, the default port 4433 follows default DTLS specification, no
change.
DTLS1.2 runs at 4433, no change.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] How are we planning to deprecate TLS 1.2?

[Viktor Dukhovni]

On Fri, Mar 03, 2023 at 03:49:28PM -0800, Watson Ladd wrote:

> > 20 years is a long time.  We can only reason about shorter timelines.
> > In the next ~5 years, I don't yet see a defensible reason to deprecate
> > TLS 1.2.
> 
> 20 years from today we'll be dealing with products shipped out today.
> Doesn't it make sense to start saying TLS 1.2 will sunset at some day?

Products shipped today will typically support and prefer to negotiate
TLS 1.3, the ones that choose to not implement TLS 1.2 probably have a
reason for that choice.

The more positive message is encourage adoption of TLS 1.3 in all market
segments where it is applicable.  TLS 1.2 does not look so broken that
we need to apply a stick rather than offer a carrot.

-- 
Viktor.

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