[TLS] Re: PQ Cipher Suite I-Ds: adopt or not?

2024-12-23 Thread John Mattsson 
The thread starts with “Due to this, Cisco has preliminarily considered Kyber 
unusable”
This is obviously not true anymore as Scott very clearly stated that Cisco 
wants to see both hybrid and non-hybrid ML-KEM standardized, and that they want 
to implement and ship both. I agree with Scott. Also, I think Cisco was quite 
clear on that if the IPR uncertainties regarding ML-KEM was not addresses, 
which they were, they wanted NTRU, not NTRU Prime
https://datatracker.ietf.org/doc/html/draft-fluhrer-cfrg-ntru-01

Mozilla is obviously shipping ML-KEM in Firefox. I am an avid user of Firefox, 
and I am happy to see X25519MLKEM768 on more and more webpages.

Cheers,
John

From: Loganaden Velvindron 
Date: Monday, 23 December 2024 at 02:56
To: Rob Sayre 
Cc: TLS List 
Subject: [TLS] Re: PQ Cipher Suite I-Ds: adopt or not?
If there are some patent concerns regarding ML-KEM going forward, Would
considering NTRU-Prime as a less risky option for TLS Kex?

(Please see this thread:
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdiscourse.mozilla.org%2Ft%2Fpatent-license-for-kyber%2F128114&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49fe1a69fb24e159b5808dd22f5004a%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638705157893766686%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Fi1LM1Q49lgZfAwBOQf5HhvEXZccY%2Bjk9VXHg6yHEaU%3D&reserved=0)

There is a section about patents here: 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fntruprime.cr.yp.to%2Fwarnings.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49fe1a69fb24e159b5808dd22f5004a%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638705157893782148%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=T%2B2Ggx2ZxAV%2BCwqSvtrUlptlGHO9iYCFpCYf4Cq3xlA%3D&reserved=0


On Tue, 17 Dec 2024 at 02:53, Rob Sayre  wrote:
>
> Hi,
>
> I only support an adoption call for this one:
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-kwiatkowski-tls-ecdhe-mlkem%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49fe1a69fb24e159b5808dd22f5004a%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638705157893792936%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=D3lsZ10f5cHom9RHdadaPqHt0bSWb6Q6Cz53MBbq1PM%3D&reserved=0
>
> The other ones seem like they could wait, carefully noting that postponement 
> is not a "no" vote.
>
> thanks,
> Rob
>
>
>
>
> On Mon, Dec 16, 2024 at 2:21 PM Martin Thomson  wrote:
>>
>> On Tue, Dec 17, 2024, at 08:59, Sean Turner wrote:
>> > Is the WG consensus to run four separate adoption calls for the
>> > individual I-Ds in question?
>>
>> I would like to see adoption calls for the key exchange modes and not the 
>> signature modes.  The key exchange documents are both more ready and more 
>> urgent.
>>
>> The question of whether to set Recommended = Y for any particular choice is 
>> separable and can wait.  Keep things as Recommended = N for now.
>>
>> ___
>> 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 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: PQ Cipher Suite I-Ds: adopt or not?

2024-12-23 Thread Scott Fluhrer (sfluhrer) 
TL;DR: Historical notes: not important for the current discussion.

To be clear about whether Cisco (or actually, me – I don’t actually speak for 
Cisco, but I like to think they listen to my advice) preferred NTRU or NTRU 
Prime – I actually didn’t have a strong opinion.  I advocated NTRU because it 
made it to round 3 (rather than stopping at round 2 as NTRUPrime did), and so 
it appeared to be a bit more mature (that is, having more cryptanalysis).  If 
there was a general consensus towards NTRU Prime, we would have happily gone 
along.

Other than that, John summarized the situation well – Cisco (or actually, 
Cisco’s lawyers) are happy with how the IPR issues around ML-KEM were resolved 
and are going forward with that (with both pure and hybrid).

From: John Mattsson 
Sent: Monday, December 23, 2024 9:02 AM
To: Loganaden Velvindron ; Rob Sayre 
Cc: TLS List 
Subject: [TLS] Re: PQ Cipher Suite I-Ds: adopt or not?

The thread starts with “Due to this, Cisco has preliminarily considered Kyber 
unusable”
This is obviously not true anymore as Scott very clearly stated that Cisco 
wants to see both hybrid and non-hybrid ML-KEM standardized, and that they want 
to implement and ship both. I agree with Scott. Also, I think Cisco was quite 
clear on that if the IPR uncertainties regarding ML-KEM was not addresses, 
which they were, they wanted NTRU, not NTRU Prime
https://datatracker.ietf.org/doc/html/draft-fluhrer-cfrg-ntru-01

Mozilla is obviously shipping ML-KEM in Firefox. I am an avid user of Firefox, 
and I am happy to see X25519MLKEM768 on more and more webpages.
Cheers,
John

From: Loganaden Velvindron mailto:logana...@gmail.com>>
Date: Monday, 23 December 2024 at 02:56
To: Rob Sayre mailto:say...@gmail.com>>
Cc: TLS List mailto:tls@ietf.org>>
Subject: [TLS] Re: PQ Cipher Suite I-Ds: adopt or not?
If there are some patent concerns regarding ML-KEM going forward, Would
considering NTRU-Prime as a less risky option for TLS Kex?

(Please see this thread:
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdiscourse.mozilla.org%2Ft%2Fpatent-license-for-kyber%2F128114&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49fe1a69fb24e159b5808dd22f5004a%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638705157893766686%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Fi1LM1Q49lgZfAwBOQf5HhvEXZccY%2Bjk9VXHg6yHEaU%3D&reserved=0)

There is a section about patents here: 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fntruprime.cr.yp.to%2Fwarnings.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49fe1a69fb24e159b5808dd22f5004a%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638705157893782148%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=T%2B2Ggx2ZxAV%2BCwqSvtrUlptlGHO9iYCFpCYf4Cq3xlA%3D&reserved=0


On Tue, 17 Dec 2024 at 02:53, Rob Sayre 
mailto:say...@gmail.com>> wrote:
>
> Hi,
>
> I only support an adoption call for this one:
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-kwiatkowski-tls-ecdhe-mlkem%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49fe1a69fb24e159b5808dd22f5004a%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638705157893792936%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=D3lsZ10f5cHom9RHdadaPqHt0bSWb6Q6Cz53MBbq1PM%3D&reserved=0
>
> The other ones seem like they could wait, carefully noting that postponement 
> is not a "no" vote.
>
> thanks,
> Rob
>
>
>
>
> On Mon, Dec 16, 2024 at 2:21 PM Martin Thomson 
> mailto:m...@lowentropy.net>> wrote:
>>
>> On Tue, Dec 17, 2024, at 08:59, Sean Turner wrote:
>> > Is the WG consensus to run four separate adoption calls for the
>> > individual I-Ds in question?
>>
>> I would like to see adoption calls for the key exchange modes and not the 
>> signature modes.  The key exchange documents are both more ready and more 
>> urgent.
>>
>> The question of whether to set Recommended = Y for any particular choice is 
>> separable and can wait.  Keep things as Recommended = N for now.
>>
>> ___
>> 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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
__

[TLS] Last Call: (TLS 1.2 is in Feature Freeze) to Informational RFC

2024-12-23 Thread The IESG 

The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'TLS 1.2 is in Feature Freeze'
   as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-c...@ietf.org mailing lists by 2025-01-13. Exceptionally, comments may
be sent to i...@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


   Use of TLS 1.3 is growing and fixes some known deficiencies in TLS
   1.2.  This document specifies that outside of urgent security fixes,
   new TLS Exporter Labels, or new Application-Layer Protocol
   Negotiation (ALPN) Protocol IDs, no changes will be approved for TLS
   1.2.  This prescription does not pertain to DTLS (in any DTLS
   version); it pertains to TLS only.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/



No IPR declarations have been submitted directly on this I-D.





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

[TLS] Re: PQ Cipher Suite I-Ds: adopt or not?

2024-12-23 Thread Rob Sayre 
Hi all, since I am still on the CC list,

I took the question to be about how to organize the work. If everything is
a priority, there are no priorities.

That's why I want to do this one (and only this one), first:
https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-mlkem/

Some of the other ones look like they could benefit from waiting, in the
sense that contentious points might resolve themselves over time.

thanks,
Rob

On Mon, Dec 23, 2024 at 11:00 AM Scott Fluhrer (sfluhrer) <
sfluh...@cisco.com> wrote:

> TL;DR: Historical notes: not important for the current discussion.
>
>
>
> To be clear about whether Cisco (or actually, me – I don’t actually speak
> for Cisco, but I like to think they listen to my advice) preferred NTRU or
> NTRU Prime – I actually didn’t have a strong opinion.  I advocated NTRU
> because it made it to round 3 (rather than stopping at round 2 as NTRUPrime
> did), and so it appeared to be a bit more mature (that is, having more
> cryptanalysis).  If there was a general consensus towards NTRU Prime, we
> would have happily gone along.
>
>
>
> Other than that, John summarized the situation well – Cisco (or actually,
> Cisco’s lawyers) are happy with how the IPR issues around ML-KEM were
> resolved and are going forward with that (with both pure and hybrid).
>
>
>
> *From:* John Mattsson 
> *Sent:* Monday, December 23, 2024 9:02 AM
> *To:* Loganaden Velvindron ; Rob Sayre <
> say...@gmail.com>
> *Cc:* TLS List 
> *Subject:* [TLS] Re: PQ Cipher Suite I-Ds: adopt or not?
>
>
>
> The thread starts with “Due to this, Cisco has preliminarily considered
> Kyber unusable”
>
> This is obviously not true anymore as Scott very clearly stated that Cisco
> wants to see both hybrid and non-hybrid ML-KEM standardized, and that they
> want to implement and ship both. I agree with Scott. Also, I think Cisco
> was quite clear on that if the IPR uncertainties regarding ML-KEM was not
> addresses, which they were, they wanted NTRU, not NTRU Prime
> https://datatracker.ietf.org/doc/html/draft-fluhrer-cfrg-ntru-01
>
> Mozilla is obviously shipping ML-KEM in Firefox. I am an avid user of
> Firefox, and I am happy to see X25519MLKEM768 on more and more webpages.
>
> Cheers,
> John
>
>
>
> *From: *Loganaden Velvindron 
> *Date: *Monday, 23 December 2024 at 02:56
> *To: *Rob Sayre 
> *Cc: *TLS List 
> *Subject: *[TLS] Re: PQ Cipher Suite I-Ds: adopt or not?
>
> If there are some patent concerns regarding ML-KEM going forward, Would
> considering NTRU-Prime as a less risky option for TLS Kex?
>
> (Please see this thread:
>
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdiscourse.mozilla.org%2Ft%2Fpatent-license-for-kyber%2F128114&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49fe1a69fb24e159b5808dd22f5004a%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638705157893766686%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Fi1LM1Q49lgZfAwBOQf5HhvEXZccY%2Bjk9VXHg6yHEaU%3D&reserved=0)
> 
>
> There is a section about patents here:
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fntruprime.cr.yp.to%2Fwarnings.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49fe1a69fb24e159b5808dd22f5004a%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638705157893782148%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=T%2B2Ggx2ZxAV%2BCwqSvtrUlptlGHO9iYCFpCYf4Cq3xlA%3D&reserved=0
> 
>
>
> On Tue, 17 Dec 2024 at 02:53, Rob Sayre  wrote:
> >
> > Hi,
> >
> > I only support an adoption call for this one:
> >
> >
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-kwiatkowski-tls-ecdhe-mlkem%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb49fe1a69fb24e159b5808dd22f5004a%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638705157893792936%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=D3lsZ10f5cHom9RHdadaPqHt0bSWb6Q6Cz53MBbq1PM%3D&reserved=0
> 
> >
> > The other ones seem like they could wait, carefully noting that
> postponement is not a "no" vote.
> >
> > thanks,
> > Rob
> >
> >
> >
> >
> > On Mon, Dec 16, 2024 at 2:21 PM Martin Thomson 
> wrote:
> >>
> >> On Tue, Dec 17, 2024, at 08:59, Sean Turner wrote:
> >> > Is the WG consensus to run four separate adoption calls for the
> >> > individual I-Ds in question?
> >>
> >> I would like to see adoption calls for the key exchange modes and not
> the signature modes.  The key exchange documents are both more ready and
> more urgent.
> >>
> >> The question of whether to set Recommended = Y for any particular
> choice is separable and can wait.  Keep things as Recomme

[TLS] Weekly github digest (TLS Working Group Drafts)

2024-12-23 Thread Repository Activity Summary Bot 




Issues
--
* tlswg/tls12-frozen (+3/-2/💬0)
 3 issues created:
 - Ref: 8446->844bis (by seanturner)
   https://github.com/tlswg/tls12-frozen/issues/9 
 - Nits complaint: No Security Considerations Section (by seanturner)
   https://github.com/tlswg/tls12-frozen/issues/8 
 - Nits complaint: 2119 boilerplate (by seanturner)
   https://github.com/tlswg/tls12-frozen/issues/6 


 2 issues closed:
 - Nits complaint: 2119 boilerplate https://github.com/tlswg/tls12-frozen/issues/6 
 - Nits complaint: 2119 boilerplate https://github.com/tlswg/tls12-frozen/issues/6 




Pull requests
-
* tlswg/tls12-frozen (+3/-3/💬0)
 3 pull requests submitted:
 - Add security considerations (by richsalz)
   https://github.com/tlswg/tls12-frozen/pull/11 
 - Ref: 8446->8446bis (by seanturner)
   https://github.com/tlswg/tls12-frozen/pull/10 
 - drop 2119 boilerplate (by seanturner)
   https://github.com/tlswg/tls12-frozen/pull/7 


 3 pull requests merged:
 - Add security considerations
   https://github.com/tlswg/tls12-frozen/pull/11 
 - Ref: 8446->8446bis
   https://github.com/tlswg/tls12-frozen/pull/10 
 - drop 2119 boilerplate
   https://github.com/tlswg/tls12-frozen/pull/7 



Repositories tracked by this digest:
---
* https://github.com/tlswg/certificate-compression
* https://github.com/tlswg/dnssec-chain-extension
* https://github.com/tlswg/draft-deprecate-obsolete-kex
* https://github.com/tlswg/draft-ietf-tls-cert-abridge
* https://github.com/tlswg/draft-ietf-tls-ctls
* https://github.com/tlswg/draft-ietf-tls-ecdhe-psk-aead
* https://github.com/tlswg/draft-ietf-tls-ech-keylogfile
* https://github.com/tlswg/draft-ietf-tls-esni
* https://github.com/tlswg/draft-ietf-tls-external-psk-importer
* https://github.com/tlswg/draft-ietf-tls-grease
* https://github.com/tlswg/draft-ietf-tls-iana-registry-updates
* https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate
* https://github.com/tlswg/draft-ietf-tls-semistatic-dh
* https://github.com/tlswg/draft-ietf-tls-svcb-ech
* https://github.com/tlswg/draft-ietf-tls-ticketrequest
* https://github.com/tlswg/draft-ietf-tls-tls13-vectors
* https://github.com/tlswg/dtls-conn-id
* https://github.com/tlswg/dtls-rrc
* https://github.com/tlswg/dtls13-spec
* https://github.com/tlswg/oldversions-deprecate
* https://github.com/tlswg/rfc4492bis
* https://github.com/tlswg/rfc8447bis
* https://github.com/tlswg/sniencryption
* https://github.com/tlswg/sslkeylogfile
* https://github.com/tlswg/sslv3-diediedie
* https://github.com/tlswg/super-jumbo-record-limit
* https://github.com/tlswg/tls13-spec
* https://github.com/tlswg/tls-exported-authenticator
* https://github.com/tlswg/tls-flags
* https://github.com/tlswg/tls-key-share-prediction
* https://github.com/tlswg/tls-key-update
* https://github.com/tlswg/tls-record-limit
* https://github.com/tlswg/tls-subcerts
* https://github.com/tlswg/tls12-frozen
* https://github.com/tlswg/tls13-pkcs1
* https://github.com/tlswg/tls13-rfc
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org