[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

[Viktor Dukhovni]

On Wed, Apr 02, 2025 at 08:07:49AM +0400, Loganaden Velvindron wrote:

> I share the same view as Martin. I also support adoption but we should
> be very careful proceeding forward.

It seems fair to assume at this point that even if/when adopted the
"Recommended" status will be "N".  That aside, the IANA codepoints are
already assigned, and the protocol payloads are obvious (c2s ek, s2c
ciphertext, both from FIPS 203, and by the clear analogy with the
widely used composites).

Implementations are already deployed, though not necessarily enabled in
default configurations.  For example, in OpenSSL 3.5.0 all three
variants are implemented, but none are in the default value of the
supported groups extension:

$ openssl list -tls1_3 -tls-groups | tr ':' '\n' | grep -i mlkem
MLKEM512
MLKEM768
MLKEM1024
SecP256r1MLKEM768
X25519MLKEM768
SecP384r1MLKEM1024

The default supported groups are:

"?*X25519MLKEM768 / ?*X25519:?secp256r1 / ?X448:?secp384r1:?secp521r1 / 
?ffdhe2048:?ffdhe3072"

which means that a client key share is by default sent for
"X25519MLKEM768" and it is chosen by the server (HRR if necessary) when
mutually supported.  A client key share is also sent for "X25519" and it
is otherwise chosen by the server when mutually supported. Otherwise,
"secp256r1" (P-256) is chosen, or else one of the remaining EC groups,
or else either of the FFDHE groups.

Some wordsmithing aside, I don't see that there's much to do here, the
protocol details won't change.  Key in clients reuse will be rare, and
non-catastrophic, interoperable key reuse in servers is not possible.

It won't much difference whether this is published by the WG or the ISE,
except as to who gets to do the wordsmithing.  If the WG would rather
not deal with it, the ISE would likely save the authors a lot of bother.

If the WG would like to tweak security considerations, or otherwise
polish the text, then adoption is the opportunity to do so.

-- 
Viktor.

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

[TLS] Re: Genart last call review of draft-ietf-tls-esni-23

[Stewart Bryant]

Thank you for your clarification Eric. I concur with your approach.StewartOn 19 Mar 2025, at 21:22, Eric Rescorla  wrote:Stewart,Thanks for your review.I have changed all but the last point, which I believe is correct as-is.The final issue asked if we should replace the reference to RFC 5077to RFC 8446, but this text is correct because the reference is to partof the internal example structure in 5077 and 8446 is just agnostic ontoken structure. 5077 is being used by way of analogy, not as a partof the protocol.-EkrOn Tue, Mar 18, 2025 at 8:49 AM Stewart Bryant via Datatracker  wrote:Reviewer: Stewart Bryant
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-tls-esni-23
Reviewer: Stewart Bryant
Review Date: 2025-03-18
IETF LC End Date: 2025-03-13
IESG Telechat date: Not scheduled for a telechat

Summary:A well written document with some minor nits that are easily addressed.

Major issues: None

Minor issues: None

Nits/editorial comments:

   fields, such as the ALPN list [RFC7301].  Co-located servers with
SB> ALPN needs expanding on first use.


   or they send a GREASE ECH 
SB> I believe that GREASE is an acronym and should be expanded.


(see Section 2 of
   [DNS-TERMS]).  
SB> ID-NITS identifies the following concern:
  -- Obsolete informational reference (is this intentional?): RFC 8499 (ref.
     'DNS-TERMS') (Obsoleted by RFC 9499)
Should the reference be changed?
=

   Note that, if the cookie includes a key name, analogous to Section 4
   of [RFC5077], this may leak information if different backend servers
   issue cookies with different key names at the time of the connection.

SB> From ID-NITS
  -- Obsolete informational reference (is this intentional?): RFC 5077
     (Obsoleted by RFC 8446)

Should the reference be changed?




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

[TLS] WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

[Sean Turner]

We are continuing with our pre-announced tranche of WG adoption calls; see [0] 
for more information. This time we are issuing a WG adoption call for the 
ML-KEM Post-Quantum Key Agreement for TLS 1.3 I-D [1]. If you support adoption 
and are willing to review and contribute text, please send a message to the 
list. If you do not support adoption of this draft, please send a message to 
the list and indicate why. This call will close at 2359 UTC on 15 April 2025.

In response to other WG adoption calls, Dan Bernstein pointed out some 
potential IPR (see [2]), but no IPR disclosure has been made in accordance with 
BCP 79.  Additional information is provided here; see [3].

BCP 79 makes this important point:

  (b) The IETF, following normal processes, can decide to use
technology for which IPR disclosures have been made if it decides
that such a use is warranted.

WG members can take this information into account during this adoption call to 
determine if we should adopt these drafts.

Reminder:  This call for adoption has nothing to do with picking the 
mandatory-to-implement cipher suites in TLS.

Cheers,
Joe and Sean

[0] https://mailarchive.ietf.org/arch/msg/tls/KMOTm_lE5OIAKG8_chDlRKuav7c/
[1] https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/
[2] https://mailarchive.ietf.org/arch/msg/tls/mt4_p95NZv8duZIJvJPdZV90-ZU/
[3] https://mailarchive.ietf.org/arch/msg/spasm/GKFhHfBeCgf8hQQvhUcyOJ6M-kI/

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

[TLS] Re: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt

[Eric Rescorla]

We already had an extensive discussion on this topic, including a consensus
call,
and I don't believe that this matches the conclusion of this call.

https://mailarchive.ietf.org/arch/msg/tls/1brhJ5dtxCp1-xYPiKV8tg2uT7k/

Substantively, I am in favor of making a general requirement against reuse
for TLS 1.3, but I don't think that having such a requirement in specific
cipher suites is good.

Thanks,
-Ekr


On Tue, Mar 18, 2025 at 6:28 AM Filippo Valsorda 
wrote:

> I supported and support prohibiting key reuse, and seem to remember
> multiple other supporting voices not named John. My impression (which could
> be mistaken because these debates are really painful to keep track of) is
> actually that objections are in the rough, if we count From headers rather
> than Message-ID headers.
>
> Yes, there is no protocol police, and implementations feeling the Need for
> Speed might still do reuse. They might also use all zeroes in place of
> random bytes, since memset is faster than any DRBG! It's also easier. The
> good news is that we won't have to waste time thinking about how
> reuse-based attacks might apply to compliant implementations.
> ___
> 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: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

[tirumal reddy]

I support adoption of the draft.

-Tiru

On Tue, 1 Apr 2025 at 18:29, Sean Turner  wrote:

> We are continuing with our pre-announced tranche of WG adoption calls; see
> [0] for more information. This time we are issuing a WG adoption call for
> the ML-KEM Post-Quantum Key Agreement for TLS 1.3 I-D [1]. If you support
> adoption and are willing to review and contribute text, please send a
> message to the list. If you do not support adoption of this draft, please
> send a message to the list and indicate why. This call will close at 2359
> UTC on 15 April 2025.
>
> In response to other WG adoption calls, Dan Bernstein pointed out some
> potential IPR (see [2]), but no IPR disclosure has been made in accordance
> with BCP 79.  Additional information is provided here; see [3].
>
> BCP 79 makes this important point:
>
>   (b) The IETF, following normal processes, can decide to use
> technology for which IPR disclosures have been made if it decides
> that such a use is warranted.
>
> WG members can take this information into account during this adoption
> call to determine if we should adopt these drafts.
>
> Reminder:  This call for adoption has nothing to do with picking the
> mandatory-to-implement cipher suites in TLS.
>
> Cheers,
> Joe and Sean
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/KMOTm_lE5OIAKG8_chDlRKuav7c/
> [1]
> https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/
> [2] https://mailarchive.ietf.org/arch/msg/tls/mt4_p95NZv8duZIJvJPdZV90-ZU/
> [3]
> https://mailarchive.ietf.org/arch/msg/spasm/GKFhHfBeCgf8hQQvhUcyOJ6M-kI/
>
> ___
> 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] [IANA #1413503] expert review for draft-ietf-tls-esni (tls-extensiontype-values)

[David Dong via RT]

Dear Yoav Nir (cc: tls WG, tls-reg-review mailing list),

Following up on this; as a designated expert for the TLS ExtensionType Values 
registry, can you review the proposed registration in draft-ietf-tls-esni-23 
for us? Please note that Nick Sullivan is a co-author for this draft and that 
Rich had already approved.

Please see:

https://datatracker.ietf.org/doc/draft-ietf-tls-esni/

The due date was March 18.

If this is OK, when the IESG approves the document for publication, we'll make 
the registration at:

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

We'll act after both experts approve the registration.

With thanks,

David Dong
IANA Services Sr. Specialist

On Mon Mar 24 22:04:42 2025, david.dong wrote:
> Dear Yoav Nir (cc: tls WG, tls-reg-review mailing list),
> 
> Following up on this; as a designated expert for the TLS ExtensionType
> Values registry, can you review the proposed registration in draft-
> ietf-tls-esni-23 for us? Please note that Nick Sullivan is a co-author
> for this draft and that Rich had already approved.
> 
> Please see:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
> 
> The due date was March 18.
> 
> If this is OK, when the IESG approves the document for publication,
> we'll make the registration at:
> 
> https://www.iana.org/assignments/tls-extensiontype-values/
> 
> We'll act after both experts approve the registration.
> 
> With thanks,
> 
> David Dong
> IANA Services Sr. Specialist
> 
> 
> On Sat Mar 15 01:27:51 2025, david.dong wrote:
> > Dear Yoav Nir (cc: tls WG, tls-reg-review mailing list),
> >
> > Following up on this; as a designated expert for the TLS
> > ExtensionType
> > Values registry, can you review the proposed registration in draft-
> > ietf-tls-esni-23 for us? Please note that Nick Sullivan is a co-
> > author
> > for this draft and that Rich had already approved.
> >
> > Please see:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
> >
> > The due date is March 18.
> >
> > If this is OK, when the IESG approves the document for publication,
> > we'll make the registration at:
> >
> > https://www.iana.org/assignments/tls-extensiontype-values/
> >
> > We'll act after both experts approve the registration.
> >
> > With thanks,
> >
> > David Dong
> > IANA Services Sr. Specialist
> >
> >
> > On Thu Mar 06 21:31:55 2025, david.dong wrote:
> > > Dear Yoav Nir (cc: tls WG, tls-reg-review mailing list),
> > >
> > > As a designated expert for the TLS ExtensionType Values registry,
> > > can
> > > you review the proposed registration in draft-ietf-tls-esni-23 for
> > > us?
> > > Please note that Nick Sullivan is a co-author for this draft and
> > > that
> > > Rich had already approved.
> > >
> > > Please see:
> > >
> > > https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
> > >
> > > The due date is March 18.
> > >
> > > If this is OK, when the IESG approves the document for publication,
> > > we'll make the registration at:
> > >
> > > https://www.iana.org/assignments/tls-extensiontype-values/
> > >
> > > We'll act after both experts approve the registration.
> > >
> > > With thanks,
> > >
> > > David Dong
> > > IANA Services Sr. Specialist
> > >
> > > On Wed Feb 26 18:26:30 2025, david.dong wrote:
> > > > Hi Nick,
> > > >
> > > > Yes, that's correct; this review request is for the two new
> > > > registrations in section 11.1 in the TLS ExtensionType Values
> > > > registry, which has the registration procedure of Specification
> > > > Required.
> > > >
> > > > Thank you.
> > > >
> > > > Best regards,
> > > >
> > > > David Dong
> > > > IANA Services Sr. Specialist
> > > >
> > > > On Wed Feb 26 08:10:28 2025, nicholas.sulli...@gmail.com wrote:
> > > > > I’m conflicted out as mentioned, but I want to clarify: this
> > > > > request
> > > > > is for
> > > > > the code points in the existing extension (section 11.1), not
> > > > > the
> > > > > request
> > > > > for the alert code point (11.2) or the new extension registry
> > > > > (11.3),
> > > > > correct?
> > > > >
> > > > > On Wed, Feb 26, 2025 at 3:15 AM Salz, Rich 
> > > > > wrote:
> > > > >
> > > > > > I approve.
> > > > > >
> > > > > > The draft does not say if the existing TLS DE's will do the
> > > > > > new
> > > > > > table, but
> > > > > > I am okay with taking on that additional workload :)
> > > > > >
> > > > > >

___
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

[Sean Turner]

Hi! It looks like we have consensus to adopt this draft as a working group 
item.  Couple of things to note:

1. Authors, please submit the draft named as: draft-ietf-tls-ecdhe-mlkem
2. Authors, please make no changes other than the boilerplate, e.g., name, 
dates to the -00 WG version
3. WG: We will continue on with the other WG adoption calls as discussed on 
list and at IETF 122.

Cheers,
spt

> On Mar 10, 2025, at 9:58 PM, Sean Turner  wrote:
> 
> Just a quick reminder that this adoption call is still ongoing.
> 
> spt
> 
>> On Feb 28, 2025, at 1:56 PM, 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.  Additional information is provided here; see [1].
>> 
>> BCP 79 makes this important point:
>> 
>> (b) The IETF, following normal processes, can decide to use
>>   technology for which IPR disclosures have been made if it decides
>>   that such a use is warranted.
>> 
>> WG members can take this information into account during this adoption call 
>> to determine if we should adopt these drafts. If this information changes a 
>> view that you have already expressed during this WG adoption call, please 
>> post a follow-up message. We also extend the WG adoption call to 14 March 
>> 2025.
>> 
>> Reminder:  This call for adoption has nothing to do with picking the 
>> mandatory-to-implement cipher suites in TLS.
>> 
>> 
>> Cheers,
>> Joe and Sean
>> 
>> [0] https://mailarchive.ietf.org/arch/msg/tls/mt4_p95NZv8duZIJvJPdZV90-ZU/
>> [1] https://mailarchive.ietf.org/arch/msg/spasm/GKFhHfBeCgf8hQQvhUcyOJ6M-kI/
>> 
>>> On Feb 26, 2025, at 1:26 PM, Sean Turner  wrote:
>>> 
>>> At IETF 121, the WG discussed “Post-Quantum Hybrid ECDHE-MLKEM Key 
>>> Agreement for TLSv1.3”; see [0] and [1]. We also had some discussion in an 
>>> information gathering thread; see [2]. We would like to now determine 
>>> whether there is support to adopt this I-D. If you support adoption and are 
>>> willing to review and contribute text, please send a message to the list. 
>>> If you do not support adoption of this I-D, please send a message to the 
>>> list and indicate why. This WG adoption call will close at 2359 UTC on 12 
>>> March 2025.
>>> 
>>> One special note: this adoption call has nothing to do with picking the 
>>> mandatory-to-implement cipher suites in TLS.
>>> 
>>> Thanks,
>>> Sean & Joe
>>> 
>>> [0] Link to I-D: 
>>> https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/
>>> [1] Link to slides: 
>>> https://datatracker.ietf.org/meeting/121/materials/slides-121-tls-post-quantum-hybrid-ecdhe-mlkem-key-agreement-for-tlsv13-00
>>> [2] Link to information gather thread: 
>>> https://mailarchive.ietf.org/arch/msg/tls/yGZV5dBTcxHJhG-JtfaP6beTd68/
>> 
> 

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

[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

[Thom Wiggers]

I support adoption of this document.

Cheers,

Thom
PQ-enthousiast

Op di 1 apr 2025 om 14:59 schreef Sean Turner :

> We are continuing with our pre-announced tranche of WG adoption calls; see
> [0] for more information. This time we are issuing a WG adoption call for
> the ML-KEM Post-Quantum Key Agreement for TLS 1.3 I-D [1]. If you support
> adoption and are willing to review and contribute text, please send a
> message to the list. If you do not support adoption of this draft, please
> send a message to the list and indicate why. This call will close at 2359
> UTC on 15 April 2025.
>
> In response to other WG adoption calls, Dan Bernstein pointed out some
> potential IPR (see [2]), but no IPR disclosure has been made in accordance
> with BCP 79.  Additional information is provided here; see [3].
>
> BCP 79 makes this important point:
>
>   (b) The IETF, following normal processes, can decide to use
> technology for which IPR disclosures have been made if it decides
> that such a use is warranted.
>
> WG members can take this information into account during this adoption
> call to determine if we should adopt these drafts.
>
> Reminder:  This call for adoption has nothing to do with picking the
> mandatory-to-implement cipher suites in TLS.
>
> Cheers,
> Joe and Sean
>
> [0] https://mailarchive.ietf.org/arch/msg/tls/KMOTm_lE5OIAKG8_chDlRKuav7c/
> [1]
> https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/
> [2] https://mailarchive.ietf.org/arch/msg/tls/mt4_p95NZv8duZIJvJPdZV90-ZU/
> [3]
> https://mailarchive.ietf.org/arch/msg/spasm/GKFhHfBeCgf8hQQvhUcyOJ6M-kI/
>
> ___
> 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: Feedback on draft-bmw-tls-pake13-01.txt

[Martin Thomson]

On Tue, Mar 25, 2025, at 02:37, Eric Rescorla wrote:
> 1. Getting PQ resistance for free even with non-PQ PAKEs.
> 2. Reducing the combinatoric explosion of "groups"

I don't know that you are really getting PQ resistance if your PAKE remains 
vulnerable.  You might maintain confidentiality for that single connection, but 
if there is a possibility of impersonation (are you relying on the PAKE for 
authentication of the server?) then you lose.

Avoiding the combinatoric problem seems like a pretty high complexity tax.  
Sure, we are already in the position where we have N (number of ECC groups) x M 
(number of PQ groups) groups.  Adding a PAKE makes that N x M x P (number of 
PAKEs).  However, these are all small numbers.  Building a parallel extension 
is relatively straightforward if you model it like key exchange and use the 
obvious combiner.  But then, why did we not do that with PQ as well?

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

[TLS] Re: WG Adoption Call for ML-KEM Post-Quantum Key Agreement for TLS 1.3

[Salz, Rich]

Opposing adoption to force the document to be published in a way that can't be 
"Recommended: Y" feels like (unnecessarily) meta-gaming the IETF process.

I am not aware of any of those opposed who are doing it for this reason. 
Perhaps speculating on their reasons isn’t a good thing to do?
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org