[TLS] Opsdir telechat review of draft-ietf-tls-tls12-frozen-06

[Jen Linkova via Datatracker]

Reviewer: Jen Linkova
Review result: Ready

The document is clearly written and easy to understand even by people who knows
very little about TLS (like this reviewer ;) I think the document has no
negative impact on deployments: quite the opposite, it might motivate people to
move to TLS1.3.

I think the document is ready. I do have a minor editorial comment, feel free
to address or ignore:

"Use of TLS 1.3 [TLS13] is growing, and it fixes most known deficiencies with
TLS 1.2 [TLS12], such as encrypting more of the traffic so that it is not
readable by outsiders and removing most cryptographic primitives now considered
weak"

I'm not a native speaker but I'm afraid this sentence may be read as
'encrypting more of the traffic' and 'removing primitives" are examples of
known deficiencies, not fixes. Maybe rephrase as '...it fixes most known
deficiencies with TLS 1.2 [TLS12]. In particular, TLS 1.3 encrypting more..."?



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

[TLS] I-D Action: draft-ietf-tls-tlsflags-15.txt

[internet-drafts]

Internet-Draft draft-ietf-tls-tlsflags-15.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   A Flags Extension for TLS 1.3
   Author:  Yoav Nir
   Name:draft-ietf-tls-tlsflags-15.txt
   Pages:   9
   Dates:   2025-03-15

Abstract:

   A number of extensions are proposed in the TLS working group that
   carry no interesting information except the 1-bit indication that a
   certain optional feature is supported.  Such extensions take 4 octets
   each.  This document defines a flags extension that can provide such
   indications at an average marginal cost of 1 bit each.  More
   precisely, it provides as many flag extensions as needed at 4 + the
   order of the last set bit divided by 8.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-15

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-tlsflags-15

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

[TLS] Re: Co-Authors to be invited for one draft that requires the extension of TLS protocol

[Dmitry Belyavsky]

Do I correctly understand that you are proposing the mechanism to save some
traffic and computation when we have a previously happened communication?

On Sat, 15 Mar 2025, 16:39 Aijun Wang,  wrote:

> Hi, All TLS experts:
>
> We are seeking the experts from the TLS WG, who is/are familiar with the
> TLS protocol itself and know how to extend it to accommodate new features
> within TLS.
>
> We have provided such extensions within the TCP protocol(
> https://datatracker.ietf.org/doc/html/draft-wang-tcpm-tcp-service-affinity-option-06)
> and now want to extend it to the TLS protocol.
>
> If you have such experiences and interested to cooperate with us, please
> contact me, via mail, or on-site at Bangkok during the IETF 122 meeting.
>
> I can explain the background of such extensions with you and discuss the
> futures cooperation expectations.
>
> Aijun Wang
> China Telecom
> ___
> 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] Co-Authors to be invited for one draft that requires the extension of TLS protocol

[Aijun Wang]

Hi, All TLS experts:

We are seeking the experts from the TLS WG, who is/are familiar with the TLS 
protocol itself and know how to extend it to accommodate new features within 
TLS.

We have provided such extensions within the TCP 
protocol(https://datatracker.ietf.org/doc/html/draft-wang-tcpm-tcp-service-affinity-option-06)
 and now want to extend it to the TLS protocol.

If you have such experiences and interested to cooperate with us, please 
contact me, via mail, or on-site at Bangkok during the IETF 122 meeting.

I can explain the background of such extensions with you and discuss the 
futures cooperation expectations.

Aijun Wang
China Telecom___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

[Stephen Farrell]

Hiya,

On 15/03/2025 10:14, Russ Housley wrote:

Stephen:

I did write to Yunlei and ask for an IPR disclosure.  


Yes, and thanks for doing that.


As far as I
know, Yunlei has never participated in an IETF activity, so he has
not promised for follow the NOTE WELL.

Dan pointed the LAMPS WG to a message where KCL publicly claimed
patents related to ML-KEM (formerly known as Kyber):

https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/
m/F63mixuWBAAJ

In that same mail archive, the following statement was made by the
same person regarding these patents:

https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/Fm4cDfsx65s/
m/2NzgqoTaBAAJ


I note the following quote from the discussion (dated May 19, 2022,
5:03:08 AM) at that last URL: "Yes, certainly we can make such an
official claims about patents as you suggest. It may formally start the
work after NIST or other standard organizations show the applicability
interest." Maybe I'm being optimistic, but if that the and other
statements about those patents only being intended defensively are
the case, it'd seem like that set of inventors might be incented to
make an IETF IPR declaration if asked, e.g. by a set of WG chairs
and/or ADs.

Cheers,
S.



Russ



On 28/02/2025 18:56, Sean Turner wrote:

In response to the WG adoption call, Dan Bernstein pointed out
some potential IPR (see [0]), but no IPR disclosure has been
made in accordance with BCP 79.


While I don't think the lack of an IPR declaration is fatal 
here, I do think it'd be great if that uncertainty could be 
reduced. I think I saw that Russ tried to reach out to one of

the possible patent holders to ask if they'd be willing to make
a declaration. I've no idea where that's at, but I'd encourage
the TLS chairs and SEC ADs to see if they can help get that to
happen as reducing uncertainty would be good and if we can't,
then this topic will just keep cropping up and Dan is not the
only person I've heard express concerns in this regard.

Cheers, S.

PS: I do realise we can't force someone to make an IPR 
declaration.











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: tls@ietf122: agenda

[Sean Turner]

Revised agenda posted; this indicates my best question as to when the 
presentations will fall.

stp

> On Mar 7, 2025, at 10:11 AM, Sean Turner  wrote:
> 
> Hi! We have posted the draft agenda for the tls@ietf122 session. The draft 
> agenda can be found here:
> https://datatracker.ietf.org/doc/agenda-122-tls/
> If I forgot anybody please let the chairs know; send 
> . Remember that at this meeting we have two 
> sessions for a total of three hours.
> 
> spt

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

[TLS] Re: Co-Authors to be invited for one draft that requires the extension of TLS protocol

[Aijun Wang]

Hi, Dmitry:We want to switch the TLS connection quickly to another address of the same server, to keep the following transaction traffic stick to the same server, that is to say, keep the service affinity during the network fluctuations.The previous address of the server is one ANYCAST address that are shared by several servers that can provide the same service.Once the network entry device selects the optimal server to communicate(based on the network conditions and server’s capabilities in real time), we want to keep the following transaction traffic stick to this server, then we should use one unique address of this server.Aijun WangChina TelecomAijun WangChina TelecomOn Mar 16, 2025, at 04:10, 【外部账号】Dmitry Belyavsky  wrote:Do I correctly understand that you are proposing the mechanism to save some traffic and computation when we have a previously happened communication? On Sat, 15 Mar 2025, 16:39 Aijun Wang,  wrote:Hi, All TLS experts:We are seeking the experts from the TLS WG, who is/are familiar with the TLS protocol itself and know how to extend it to accommodate new features within TLS.We have provided such extensions within the TCP protocol(https://datatracker.ietf.org/doc/html/draft-wang-tcpm-tcp-service-affinity-option-06) and now want to extend it to the TLS protocol.If you have such experiences and interested to cooperate with us, please contact me, via mail, or on-site at Bangkok during the IETF 122 meeting.I can explain the background of such extensions with you and discuss the futures cooperation expectations.Aijun WangChina Telecom___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

___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] First look at draft-bmw-tls-pake13-01.txt

[Eric Rescorla]

I gave this document an initial read. At a high level this seems like
a good start if the TLS WG is going to pursue PAKE bindings to TLS
1.3. With that said, given the longish history of PAKEs in TLS,
I'd like to be sure that we have critical mass for implementation,
so if we get to the point of an adoption call, I'd encourage
the chairs to be really sure there is enough interest in deployment
to justify this work.


A few detailed comments below...


It would be good to understand the deployment model here a little
better. S 4.2 prohibits the use of PAKEs with either PSKs or
Certificates, which I believe means that the only form of server
authentication is the PAKE. It seems like this is OK in some
circumstances, but it seems like if:

1. The client uses the same password on example.com and attacker.com
and
2. The attacker ever learns the password

Then the attacker can impersonate example.com to the user.

I would make two points here:

1. If you use a non-augmented PAKE, then things are very bad, but this
   draft doesn't seem to require an augmented PAKE.
1. Even with an augmented PAKE, you're still relying fairly heavily on
   the security of the PBKDF. If the user uses a common password, then
   the attacker can still brute force it.

I understand that this may not seem like that serious an attack
because if the attacker knows the password they can impersonate the
client to the server, but the other direction is also an issue because
it allows the attacker to lie to the client or to induce the client to
send them secrets (please reenter your SSN...). Assuming I'm not
wrong, then I think at minimum we need some kind of warning about this
case, and probably to to discourage it in contexts like the Web where
there is some other notion of identity. In particular, I think it
would be bad to have the following:

- Alice connects to example.com over HTTPS authenticated with a
  certificate and registers a password.
- Alice reconnects to example.com over HTTPS and uses a PAKE
  and this is treated as same origin with https://example.com

Note that this wouldn't necessarily be the case if you allowed the
combination of certificate-based auth and the PAKE, though that might
be problematic for other reasons.


Per S 4.2, if you use the PAKE then you don't do ECDHE at all
(i.e., you don't send key_share). This seems like it means
that you can't get any resistance to quantum computers unless
you have a PQ PAKE (which AFAIK SPAKE2+ is not). It seems like
if you also did the standard TLS 1.3 key establishment, then you
could use a PQ or PQ-hybrid algorithm and get protection against
harvest-now-decrypt-later attacks, though of course not against
impersonation if the attacker has a CRQC.

On a related topic, I note that the OPAQUE binding in
draft-sullivan-tls-opaque makes use of the TLS 1.3 key shares,
so I'm curious how you would do an OPAQUE binding here.

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

[TLS] Re: Co-Authors to be invited for one draft that requires the extension of TLS protocol

[rs...@akamai.com]

We want to switch the TLS connection quickly to another address of the same 
server, to keep the following transaction traffic stick to the same server … 
The previous address of the server is one ANYCAST address that are shared by 
several servers that can provide the same service.

Are you trying to handle network path changes between client and server? This 
is often called multi-path, and you might want to look at the QUIC multipath 
drafts for some ideas.

Or, are you trying to handle the case where the client is now connected to a 
different server, at the same anycast address? I would think that only works if 
either (a) all servers share all state; or (b) the client knows and start a new 
resumption to the new server.

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

[TLS] Re: Co-Authors to be invited for one draft that requires the extension of TLS protocol

[Aijun Wang]

Hi, Rich:

I knew QUIC had such mechanism, as that are described in 
https://www.rfc-editor.org/rfc/rfc9000.html#name-connection-migration. We just 
want to implement the similar procedure in TLS, for different scenarios, at the 
beginning of TLS handshake as quickly as possible.

Regarding to your proposal, b) is the ideal procedure. We need some negotiation 
at the TLS handshake phase, to let the server tell the client it’s switched 
unique address, to replace the original ANYCAST address.

Aijun Wang
China Telecom

> On Mar 16, 2025, at 08:15, 【外部账号】 rs...@akamai.com  wrote:
> 
> 
> We want to switch the TLS connection quickly to another address of the same 
> server, to keep the following transaction traffic stick to the same server … 
> The previous address of the server is one ANYCAST address that are shared by 
> several servers that can provide the same service.
>  
> Are you trying to handle network path changes between client and server? This 
> is often called multi-path, and you might want to look at the QUIC multipath 
> drafts for some ideas.
>  
> Or, are you trying to handle the case where the client is now connected to a 
> different server, at the same anycast address? I would think that only works 
> if either (a) all servers share all state; or (b) the client knows and start 
> a new resumption to the new server.
>  
> ___
> 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: First look at draft-bmw-tls-pake13-01.txt

[Rob Sayre]

On Sat, Mar 15, 2025 at 4:55 PM Eric Rescorla  wrote:

>
> Note that this wouldn't necessarily be the case if you allowed the
> combination of certificate-based auth and the PAKE, though that might
> be problematic for other reasons.
>

That was exactly my thought. I think I have seen some OPAQUE drafts that
don't start from "0" in the key schedule.

So, what are the "other reasons"? Not meant as sarcastic scare quotes. But,
what are they?

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

[TLS] Feedback on draft-bmw-tls-pake13-01.txt

[Laura Bauman]

Thanks to everyone that has taken a look at draft-bmw-tls-pake13-01.txt and 
provided feedback so far. As more people start reading it, I wanted to clarify 
that the current draft version does not yet reflect the change we intend to 
make to allow Certificates and the pake extension to be used together. We’ve 
filed a GitHub issue here tracking our intent to change this: 
https://github.com/chris-wood/draft-bmw-tls-pake13/issues/25.

Thanks,

Laura Bauman
l_bau...@apple.com___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

[TLS] Re: Co-Authors to be invited for one draft that requires the extension of TLS protocol

[rs...@akamai.com]

Thank you for the clarification.  It is an interesting problem to think about, 
especially when you think that the change might be introduced by “the network” 
or by “the client”, such as when the user moves from home to office.

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

[TLS] Re: First look at draft-bmw-tls-pake13-01.txt

[Eric Rescorla]

On Sat, Mar 15, 2025 at 6:19 PM Rob Sayre  wrote:

> On Sat, Mar 15, 2025 at 4:55 PM Eric Rescorla  wrote:
>
>>
>> Note that this wouldn't necessarily be the case if you allowed the
>> combination of certificate-based auth and the PAKE, though that might
>> be problematic for other reasons.
>>
>
> That was exactly my thought. I think I have seen some OPAQUE drafts that
> don't start from "0" in the key schedule.
>
> So, what are the "other reasons"? Not meant as sarcastic scare quotes.
> But, what are they?
>

I'm not sure there necessarily are any; I just haven't thought through the
problem completely
and so wanted to leave room for there being some barrier I wasn't aware of.

With that said, it seems like you would want to have some formal
verification that
the PAKE and certificate-based auth played well together, and in particular
that
they were non-separable.

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