Re: [TLS] [EXTERNAL] Re: TLS 1.2 deprecation

[Rob Sayre]

Hi.

The point here is not to debate "post_handshake_auth" in TLS 1.2. It's to
point out that this extension is already in the registry. So, you already
have fairly serious parts of the handshake that don't fit in TLS 1.2.

So, what to do now? I think the deprecation path in the meeting makes sense.

thanks,
Rob

On Thu, Mar 30, 2023 at 7:29 PM Andrei Popov 
wrote:

> IMHO, no reason to add post_handshake_auth to TLS 1.2, because TLS 1.2
> already supports renegotiation.
>
> While renegotiation had its share of issues we had to patch over time,
> doing TLS 1.2 client auth without renegotiation leaks client identity.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* TLS  *On Behalf Of * Rob Sayre
> *Sent:* Friday, March 31, 2023 8:20 AM
> *To:* David Benjamin 
> *Cc:* TLS@ietf.org
> *Subject:* [EXTERNAL] Re: [TLS] TLS 1.2 deprecation
>
>
>
> On Thu, Mar 30, 2023 at 3:58 PM David Benjamin 
> wrote:
>
> post_handshake_auth was only in TLS 1.3 because some folks relied on an
> existing (and terrible :-) ) corresponding mechanism in TLS 1.2: trigger a
> renegotiation and request a client certificate in the new handshake. I
> don't think it makes sense to backport post_handshake_auth to TLS 1.2. Such
> a backport would also require much more analysis than the average
> extension, since it concerns authentication.
>
>
>
> No disagreement from me. My point was only that such things are already in
> the IANA registry.
>
>
>
> thanks,
>
> Rob
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] [EXTERNAL] Re: TLS 1.2 deprecation

[Andrei Popov]

IMHO, no reason to add post_handshake_auth to TLS 1.2, because TLS 1.2 already 
supports renegotiation.
While renegotiation had its share of issues we had to patch over time, doing 
TLS 1.2 client auth without renegotiation leaks client identity.

Cheers,

Andrei

From: TLS  On Behalf Of Rob Sayre
Sent: Friday, March 31, 2023 8:20 AM
To: David Benjamin 
Cc: TLS@ietf.org
Subject: [EXTERNAL] Re: [TLS] TLS 1.2 deprecation

On Thu, Mar 30, 2023 at 3:58 PM David Benjamin 
mailto:david...@chromium.org>> wrote:
post_handshake_auth was only in TLS 1.3 because some folks relied on an 
existing (and terrible :-) ) corresponding mechanism in TLS 1.2: trigger a 
renegotiation and request a client certificate in the new handshake. I don't 
think it makes sense to backport post_handshake_auth to TLS 1.2. Such a 
backport would also require much more analysis than the average extension, 
since it concerns authentication.

No disagreement from me. My point was only that such things are already in the 
IANA registry.

thanks,
Rob

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

Re: [TLS] TLS 1.2 deprecation and RFC 7627

[Salz, Rich]

FWIW, my plan for the draft (which I hope to submit for adoption within a 
month) is to include text that says, basically, while no new features will be 
ADDED to TLS 1.2, the WG may decide to deprecate or remove things that have 
become security risks.  I think it's better to keep specifics in separate 
documents; ideally this one can be read, understood, and appreciated by those 
not steeped in the gory technical details.

On 3/31/23, 8:59 AM, "Martin Thomson" mailto:m...@lowentropy.net>> wrote:


Just a thought, but in the discussion of TLS 1.2, we might start to consider 
the use of TLS 1.2 **without the session hash/EMS** extension to be deprecated 
sooner. RFC 7627 basically rescued TLS 1.2 from a whole swathe of problems; so 
maybe requiring it (or not supporting TLS 1.2 if that cannot be negotiated) 
offers a short term step toward eventual deprecation, while allowing those who 
find themselves stuck on TLS 1.2 more time to adjust.


___
TLS mailing list
TLS@ietf.org 
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!UNB0h17Crh0iXqtbjQkhlf5180NWCg6SrAVjadF2H-Era8IqokFYAERHtHrNs3kfu9iwp7h9kw$
 

 



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

[TLS] TLS 1.2 deprecation and RFC 7627

[Martin Thomson]

Just a thought, but in the discussion of TLS 1.2, we might start to consider 
the use of TLS 1.2 **without the session hash/EMS** extension to be deprecated 
sooner.  RFC 7627 basically rescued TLS 1.2 from a whole swathe of problems; so 
maybe requiring it (or not supporting TLS 1.2 if that cannot be negotiated) 
offers a short term step toward eventual deprecation, while allowing those who 
find themselves stuck on TLS 1.2 more time to adjust.

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

Re: [TLS] TLS 1.2 deprecation

[Rob Sayre]

On Thu, Mar 30, 2023 at 3:58 PM David Benjamin 
wrote:

> post_handshake_auth was only in TLS 1.3 because some folks relied on an
> existing (and terrible :-) ) corresponding mechanism in TLS 1.2: trigger a
> renegotiation and request a client certificate in the new handshake. I
> don't think it makes sense to backport post_handshake_auth to TLS 1.2. Such
> a backport would also require much more analysis than the average
> extension, since it concerns authentication.
>

No disagreement from me. My point was only that such things are already in
the IANA registry.

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

Re: [TLS] TLS 1.2 deprecation

[David Benjamin]

post_handshake_auth was only in TLS 1.3 because some folks relied on an
existing (and terrible :-) ) corresponding mechanism in TLS 1.2: trigger a
renegotiation and request a client certificate in the new handshake. I
don't think it makes sense to backport post_handshake_auth to TLS 1.2. Such
a backport would also require much more analysis than the average
extension, since it concerns authentication.

On Fri, Mar 31, 2023 at 5:27 AM Rob Sayre  wrote:

> Hi,
>
> What I noticed is that something close to "post_handshake_auth" has been
> asked for in TLS 1.2.
>
> If you go look at the registry, which of course some people here know
> well, there are a bunch of them that are only defined for TLS 1.3.
>
>
> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
>
> Some of them would not make sense in a TLS 1.2 handshake, by my reading.
> So, the drift is already happening, quite apart from new feature
> development.
>
> thanks,
> Rob
>
>
> On Wed, Mar 29, 2023 at 10:05 PM Rob Sayre  wrote:
>
>> Hi,
>>
>> I watched the conversation at the end of this conference here:
>> https://youtu.be/u_sFyz4F7dc
>>
>> It was good. The only thing I would add is that I think client
>> authentication is already much different in 1.3, and that new extensions
>> such as ECH are already not being done for 1.2.
>>
>> The thing to do if you have a strong opinion is to not serve 1.2 traffic.
>> The clients will always have to be accepting for a while. But, if you've
>> worked on the internet for any amount of time, you'll quickly figure out
>> that not serving 1.2 will save you money, unless you are Google scale. Not
>> because it is way slower, but because you can drop old clients.
>>
>> thanks,
>> Rob
>>
>>
>>
>> ___
> 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] TLS 1.2 deprecation

[Rob Sayre]

Hi,

What I noticed is that something close to "post_handshake_auth" has been
asked for in TLS 1.2.

If you go look at the registry, which of course some people here know well,
there are a bunch of them that are only defined for TLS 1.3.

https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml

Some of them would not make sense in a TLS 1.2 handshake, by my reading.
So, the drift is already happening, quite apart from new feature
development.

thanks,
Rob


On Wed, Mar 29, 2023 at 10:05 PM Rob Sayre  wrote:

> Hi,
>
> I watched the conversation at the end of this conference here:
> https://youtu.be/u_sFyz4F7dc
>
> It was good. The only thing I would add is that I think client
> authentication is already much different in 1.3, and that new extensions
> such as ECH are already not being done for 1.2.
>
> The thing to do if you have a strong opinion is to not serve 1.2 traffic.
> The clients will always have to be accepting for a while. But, if you've
> worked on the internet for any amount of time, you'll quickly figure out
> that not serving 1.2 will save you money, unless you are Google scale. Not
> because it is way slower, but because you can drop old clients.
>
> thanks,
> Rob
>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] A comment on draft-mattsson-tls-psk-ke-dont-dont-dont

[Ilari Liusvaara]

It seems that draft-mattsson-tls-psk-ke-dont-dont-dont also deprecates
some other stuff. However, it does not seem to deprecate session_ticket
(recommended=Y!).

That extension is flawed in multiple ways, and those flaws interact in
nasty ways, with end result worse than psk_ke. If psk_ke warrants being
marked as recommended=D, then session_ticket definitely also does.

If server has session tickets enabled, then STEK is master key to
decrypt all TLS 1.2 connections that advertise session_ticket.
Furthermore, unless server has explicit checks to limit total session
lifetime (which is not the same as ticket age), attacker can roll over
tickets to new STEK.



-Ilari

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