Re: [TLS] draft-ietf-tls-cert-abridge Update

Hi Panos, On 05/03/2024 04:14, Kampanakis, Panos wrote: Hi Dennis, > I can see two different ways to handle it. Either as you suggest, we have it be a runtime decision and we just prefix the compressed form with a byte to indicate whether pass 2 has been used. Alternatively, we can define t

Re: [TLS] draft-ietf-tls-cert-abridge Update

But I thought retired people were supposed to sleep in? From: TLS On Behalf Of Dennis Jackson Sent: Wednesday, March 6, 2024 7:39 AM To: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-cert-abridge Update [External email] Hi Panos, On 05/03/2024 04:14, Kampanakis, Panos wrote: Hi Den

Re: [TLS] ML-KEM key agreement for TLS 1.3

Deirdre, thanks for submitting this. Can you say what the motivation is for being "fully post-quantum" rather than hybrid? Thanks, -Ekr On Tue, Mar 5, 2024 at 6:16 PM Deirdre Connolly wrote: > I have uploaded a preliminary version of ML-KEM for TLS 1.3 >

Re: [TLS] ML-KEM key agreement for TLS 1.3

Thanks Deirdre, I would like to use hybrid but I strongly believe that registering things as standalone NamedGroups and then let TLS negotiate which combinations to use is the right one long-term. This is the approch chosen be IKEv2. - As EKR pointed out the word "fully" would need explanation

Re: [TLS] ML-KEM key agreement for TLS 1.3

I think TLS should register all algorithm variants standardized by NIST. That means ML-KEM-512, ML-KEM-768, and ML-KEM-1024. And in the future a subset of HQC/BIKE/Classic McEliece. I think the TLS discussions are way too focused on a single ephemeral key exchange. A growing use of TLS is for m

Re: [TLS] ML-KEM key agreement for TLS 1.3

On Wed, Mar 06, 2024 at 04:25:16PM +, John Mattsson wrote: > I think TLS should register all algorithm variants standardized by > NIST. That means ML-KEM-512, ML-KEM-768, and ML-KEM-1024. And in > the future a subset of HQC/BIKE/Classic McEliece. Just as note, supporting Classic McEliece is no

Re: [TLS] ML-KEM key agreement for TLS 1.3

> Can you say what the motivation is for being "fully post-quantum" rather than hybrid? Sure: in the broad scope, hybrid introduces complexity in the short-term that we would like to move off of in the long-term - for TLS 1.3 key agreement this is not the worst thing in the world and we can afford

Re: [TLS] ML-KEM key agreement for TLS 1.3

> I don't understand. We align with hybrid by not being hybrid? Ah sorry, I mean on the design of how the client shares an ephemeral encapsulation key in their `ClientHello` and how the server replies with the ciphertext in their `ServerHello`, and generally aligning in design and encoding with -

Re: [TLS] ML-KEM key agreement for TLS 1.3

My current draft does not include ML-KEM-512, mostly because there seems to be alignment around ML-KEM-768 being ~equivalent to say X25519 or P-256 ECDH in terms of security level. I'm not married strongly to excluding it but that was kind of the thinking. On Wed, Mar 6, 2024 at 11:25 AM John Matt

Re: [TLS] ML-KEM key agreement for TLS 1.3

On Wed, Mar 6, 2024 at 8:49 AM Deirdre Connolly wrote: > > Can you say what the motivation is for being "fully post-quantum" rather > than hybrid? > > Sure: in the broad scope, hybrid introduces complexity in the short-term > that we would like to move off of in the long-term - for TLS 1.3 key >

Re: [TLS] ML-KEM key agreement for TLS 1.3

> So I think the question here should be focused on "what level of confidence would IETF need to specify ML-KEM standalone at Proposed Standard with Recommended=Y". On 'Recommended=Y' I figured it would not be for a while, but it is available. > I don't think there is anywhere near enough confid

Re: [TLS] ML-KEM key agreement for TLS 1.3

Andrey Jivsov writes: > Does this point apply in your opinion to hash-based signatures? Yes. Here's a comment I made about this topic in CFRG a few weeks ago: "I've sometimes run into people surprised that I recommend _always_ using hybrids rather than making exceptions for McEliece and SPHINCS+.

[TLS] Draft on "TLS 1.2 feature freeze"

The draft, having been adopted, is now part of the TLSWG github repository at [1] Once the posting freeze is over I’ll post a version. The only real change from the call-for-adoption one is that it now says Bluntly, post-quantum cryptography for TLS 1.2 WILL NOT be supported I d

Re: [TLS] ML-KEM key agreement for TLS 1.3

On Wed, Mar 6, 2024 at 9:22 AM Eric Rescorla wrote: > > > On Wed, Mar 6, 2024 at 8:49 AM Deirdre Connolly > wrote: > >> > Can you say what the motivation is for being "fully post-quantum" >> rather than hybrid? >> >> Sure: in the broad scope, hybrid introduces complexity in the short-term >> tha

Re: [TLS] ML-KEM key agreement for TLS 1.3

On Wed, Mar 6, 2024, 10:48 AM Rob Sayre wrote: > > On Wed, Mar 6, 2024 at 9:22 AM Eric Rescorla wrote: >> >> >> >> On Wed, Mar 6, 2024 at 8:49 AM Deirdre Connolly >> wrote: >>> >>> > Can you say what the motivation is for being "fully post-quantum" rather >>> > than hybrid? >>> >>> Sure: in th

Re: [TLS] ML-KEM key agreement for TLS 1.3

I'd like to understand the argument for why a transition back to single schemes would be desirable. Having hybrids be the new standard seems to be a nice win for security and pretty much negligible costs in terms of performance, complexity and bandwidth (over single PQ schemes). On 07/03/202

Re: [TLS] draft-ietf-tls-cert-abridge Update

Good point, understood, thanks. > I was suggesting either have it be a single label for the entire message or > putting the label into the TLS1.3 Cert Compression codepoint. I think the former sounds more reasonable. 2 codepoints for (only CA pass 1 compression) and (Pass1+Pass2) seems to be wa

Re: [TLS] ML-KEM key agreement for TLS 1.3

The cost of hybrids is not high, but it's certainly not negligible. I can't share the exact number of servers we'd be able to cut if we'd go pure PQ, but with a back of the envelope calculation I think you can convince yourself that we could've at least hired an engineer instead. We think it's wort

Re: [TLS] ML-KEM key agreement for TLS 1.3

Back to the topic at hand. I think it'd very bad if we'd have a codepoint for pure ML-KEM before we have a codepoint for an ML-KEM hybrid. Process wise, I think that's up to the designated experts of the IANA registry. Best, Bas On Wed, Mar 6, 2024 at 3:16 AM Deirdre Connolly wrote: > I have

Re: [TLS] ML-KEM key agreement for TLS 1.3

No objection there 👍 On Wed, Mar 6, 2024, 11:10 PM Bas Westerbaan wrote: > Back to the topic at hand. I think it'd very bad if we'd have a codepoint > for pure ML-KEM before we have a codepoint for an ML-KEM hybrid. Process > wise, I think that's up to the designated experts of the IANA registry

Re: [TLS] ML-KEM key agreement for TLS 1.3

Does the argument about hybrid code points first generalize to all PQ Code points? Is it equally true of hybrid signatures? I don't understand why registering composite components first wouldn't be assumed. Isn't support for the component mandatory to support the hybrid anyway? Let's assume CRQ

Re: [TLS] ML-KEM key agreement for TLS 1.3

> Isn't support for the component mandatory to support the hybrid anyway? Strictly speaking, not necessarily: I could see support for X-Wing or another hybrid key agreement as a standalone unit, both from a software dependency perspective and protocol API perspective. Whether that works in the lon