Re: [TLS] [EXT] Re: What is the TLS WG plan for quantum-resistant algorithms?

2023-11-06 Thread Yoav Nir 


> On 7 Nov 2023, at 0:29, Blumenthal, Uri - 0553 - MITLL  
> wrote:
> 
> Do we want rfc describing the final NIST standards? And for which? I'm ok 
> with that — in this order of priority: ml-kem, ml-dsa, slh-dsa.
>  
> Probably yes, and in the order you described.

Sure, as long as by “describe” we mean “reference”.  NIST do a great job of 
describing algorithms. We don’t need to replicate that effort, only to show 
encoding in a particular protocol and choose when several options are available.
 
> For which algorithms do we want to assign codepoints once the NIST standards 
> are out? Codepoints are cheap and use cases/rules are different, but 
> especially with the hybrids, I'd encourage us to try to be disciplined and 
> keep the list as short as we can for now, so that early adopters for which it 
> doesn't matter, all choose the same thing. The DNS mechanism of 
> draft-davidben-tls-key-share-prediction helps on the performance side, but it 
> doesn't solve the duplicate engineering/validation if there are a dozen 
> essentially equivalent KEMs.
>  
> Leaving this question alone, at least for now.
>  
> Do we want to standardise non-hybrid KEMs for TLS? I don't care for them yet, 
> but others might.
>  
> Absolutely yes.

Yes. They're that end goal mentioned upthread. 

> Do we need hybrid signatures for the TLS handshake? I don't see the use, but 
> could be convinced otherwise.
>  
> I don’t need/want them, but can’t/won’t forbid others from using them. They 
> still don’t make sense to me.

Signatures generally follow from what’s in the certificate. So if certificates 
are going to have hybrid keys, it makes sense for the protocol to have hybrid 
signatures.
It’s still an open question if certificates are going to have hybrid keys. 
LAMPS has not spoken beyond not adopting a draft.

> What is the future of AuthKEM? That's definitely a different e-mail thread.
>  
> I hope it becomes a mainstream standard.
>  
> Concretely, after ML-KEM is finished, I was planning to update 
> draft-schwabe-cfrg-kyber to match it, and proposing to register a codepoint 
> for a single ML-KEM-768 hybrid in draft-ietf-tls-hybrid-design.
>  
> Great!
>  
> Thanks 
>  
> On Mon, Nov 6, 2023 at 10:10 AM John Mattsson 
>  > wrote:
>> Hi,
>> 
>> NIST has released draft standards for ML-KEM, ML-DSA, and ML-SLH. Final 
>> standards are expected in Q1 2024.
>> https://csrc.nist.gov/news/2023/three-draft-fips-for-post-quantum-cryptography
>>  
>> I would like to have standard track TLS (and DTLS, QUIC) RFCs for ML-KEM and 
>> ML-DSA (all security levels standardized by NIST) as soon as possible after 
>> the final NIST standards are ready. 3GPP is relying almost exclusively on 
>> IETF RFCs for uses of public key cryptography (the exception is ECIES for 
>> IMSI encryption but that will likely use HPKE with ML-KEM in the future).
>>  
>> Looking at the TLS document list, it seems severely lacking when it comes to 
>> ML-KEM, ML-DSA…
>>  
>> The adopted draft-ietf-tls-hybrid-design is an informal draft dealing with 
>> the pre-standard Kyber. 
>> https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>> 
>> AuthKEM is a quite big change to TLS
>> https://datatracker.ietf.org/doc/draft-wiggers-tls-authkem-psk/
>>  
>> This is not adopted, informal, and dealing with the pre-standard Kyber.
>> https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-kyber/
>>  
>> What is the TLS WG plan for quantum-resistant algorithms? My current view is 
>> that I would like ML-KEM-512, ML-KEM-768, ML-KEM-1024, ML-DSA-44, ML-DSA-65, 
>> and ML-DSA-87 registered asap. For hybrid key exchange I think X25519 and 
>> X448 are the only options that make sense. For hybrid signing, ECDSA, EdDSA, 
>> and RSA could all make sense.
>>  
>> Cheers,
>> John
>>  
>> From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
>> internet-dra...@ietf.org  
>> mailto:internet-dra...@ietf.org>>
>> Date: Friday, 8 September 2023 at 02:48
>> To: i-d-annou...@ietf.org  
>> mailto:i-d-annou...@ietf.org>>
>> Cc: tls@ietf.org  mailto:tls@ietf.org>>
>> Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-09.txt
>> 
>> Internet-Draft draft-ietf-tls-hybrid-design-09.txt is now available. It is a
>> work item of the Transport Layer Security (TLS) WG of the IETF.
>> 
>>Title:   Hybrid key exchange in TLS 1.3
>>Authors: Douglas Stebila
>> Scott Fluhrer
>> Shay Gueron
>>Name:draft-ietf-tls-hybrid-design-09.txt
>>Pages:   23
>>Dates:   2023-09-07
>> 
>> Abstract:
>> 
>>Hybrid key exchange refers to using multiple key exchange algorithms
>>simultaneously and combining the result with the goal of providing
>>security even if all but one of the component algorithms is broken.
>>It is motivated by transition to post-quantum cryptography.  This
>>document provides a construction

Re: [TLS] [EXT] Re: What is the TLS WG plan for quantum-resistant algorithms?

2023-11-06 Thread Blumenthal, Uri - 0553 - MITLL 
Do we want rfc describing the final NIST standards? And for which? I'm ok with 
that — in this order of priority: ml-kem, ml-dsa, slh-dsa.
 

Probably yes, and in the order you described.

 

For which algorithms do we want to assign codepoints once the NIST standards 
are out? Codepoints are cheap and use cases/rules are different, but especially 
with the hybrids, I'd encourage us to try to be disciplined and keep the list 
as short as we can for now, so that early adopters for which it doesn't matter, 
all choose the same thing. The DNS mechanism of 
draft-davidben-tls-key-share-prediction helps on the performance side, but it 
doesn't solve the duplicate engineering/validation if there are a dozen 
essentially equivalent KEMs.
 

Leaving this question alone, at least for now.

 

Do we want to standardise non-hybrid KEMs for TLS? I don't care for them yet, 
but others might.
 

Absolutely yes.

 

Do we need hybrid signatures for the TLS handshake? I don't see the use, but 
could be convinced otherwise.
 

I don’t need/want them, but can’t/won’t forbid others from using them. They 
still don’t make sense to me.

 

What is the future of AuthKEM? That's definitely a different e-mail thread.
 

I hope it becomes a mainstream standard.

 

Concretely, after ML-KEM is finished, I was planning to update 
draft-schwabe-cfrg-kyber to match it, and proposing to register a codepoint for 
a single ML-KEM-768 hybrid in draft-ietf-tls-hybrid-design.

 

Great!

 

Thanks 

 

On Mon, Nov 6, 2023 at 10:10 AM John Mattsson 
 wrote:

Hi,


NIST has released draft standards for ML-KEM, ML-DSA, and ML-SLH. Final 
standards are expected in Q1 2024.

https://csrc.nist.gov/news/2023/three-draft-fips-for-post-quantum-cryptography

 

I would like to have standard track TLS (and DTLS, QUIC) RFCs for ML-KEM and 
ML-DSA (all security levels standardized by NIST) as soon as possible after the 
final NIST standards are ready. 3GPP is relying almost exclusively on IETF RFCs 
for uses of public key cryptography (the exception is ECIES for IMSI encryption 
but that will likely use HPKE with ML-KEM in the future).

 

Looking at the TLS document list, it seems severely lacking when it comes to 
ML-KEM, ML-DSA…

 

The adopted draft-ietf-tls-hybrid-design is an informal draft dealing with the 
pre-standard Kyber. 

https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/

AuthKEM is a quite big change to TLS

https://datatracker.ietf.org/doc/draft-wiggers-tls-authkem-psk/

 

This is not adopted, informal, and dealing with the pre-standard Kyber.

https://datatracker.ietf.org/doc/draft-kwiatkowski-tls-ecdhe-kyber/

 

What is the TLS WG plan for quantum-resistant algorithms? My current view is 
that I would like ML-KEM-512, ML-KEM-768, ML-KEM-1024, ML-DSA-44, ML-DSA-65, 
and ML-DSA-87 registered asap. For hybrid key exchange I think X25519 and X448 
are the only options that make sense. For hybrid signing, ECDSA, EdDSA, and RSA 
could all make sense.

 

Cheers,
John

 

From: TLS  on behalf of internet-dra...@ietf.org 

Date: Friday, 8 September 2023 at 02:48
To: i-d-annou...@ietf.org 
Cc: tls@ietf.org 
Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-09.txt

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

   Title:   Hybrid key exchange in TLS 1.3
   Authors: Douglas Stebila
Scott Fluhrer
Shay Gueron
   Name:draft-ietf-tls-hybrid-design-09.txt
   Pages:   23
   Dates:   2023-09-07

Abstract:

   Hybrid key exchange refers to using multiple key exchange algorithms
   simultaneously and combining the result with the goal of providing
   security even if all but one of the component algorithms is broken.
   It is motivated by transition to post-quantum cryptography.  This
   document provides a construction for hybrid key exchange in the
   Transport Layer Security (TLS) protocol version 1.3.

   Discussion of this work is encouraged to happen on the TLS IETF
   mailing list tls@ietf.org or on the GitHub repository which contains
   the draft: 
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-c404f4af2592f2f4=1=367fabf2-370b-4cec-b657-05a8499decf6=https%3A%2F%2Fgithub.com%2Fdstebila%2Fdraft-ietf-tls-hybrid-design.

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

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-09.html

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

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


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

___
TLS mailing list
TLS@ietf.org