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

Hello, I would like to express my support for getting a codepoint for ML-KEM (the queue was closed quicker than I expected, so didn’t have a chance to do it at the meeting). The motivation: * First of all the integration is rather straightforward. * MLKEM already got a large amount of

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

On Wed, Mar 6, 2024, 06:16 Deirdre Connolly wrote: > I have uploaded a preliminary version of ML-KEM for TLS 1.3 > > and have a more fleshed out > version to >

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

Of * Deirdre Connolly *Sent:* Tuesday, March 5, 2024 9:15 PM *To:* TLS@ietf.org *Subject:* [TLS] ML-KEM key agreement for TLS 1.3 I have uploaded a preliminary version of ML-KEM for TLS 1.3 <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/> and have a more fles

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

On Wed, Mar 13, 2024 at 6:39 PM Deirdre Connolly wrote: > > Some considerations for ML-KEM alone (or another trusted PQ-only key > agreement) are mainly looking towards the desired next step after hybrid key > agreement, and instead of leaving that fuzzy and far off, talking about it in > the

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

Eric Rescorla writes: > It's of course worth noting that a CRQC might be very far in the > future and we might get better PQ algorithms by that point, in which > case we'd never deploy pure ML-KEM. There are already various lattice KEMs that outperform Kyber, the most recent being

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

messages with the term "group" in them despite >>>>> using a key exchange algorithm that is not Diffie-Hellman-based nor a >>>>> group." >>>>> >>>>> This seems okay, but on the IANA registry for TLS Supported Groups, it >&g

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

Good points. I've included these notes in the GitHub tracking issue, and will leave the document as-is for now. On Thu, Mar 14, 2024, 3:41 PM Sophie Schmieg wrote: > There was a push to change the parsing logic for ML-KEM public keys to > never fail, by silently reducing, without changing the

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

; to accommodate QR KEMs. >> >> >> >> 4. In the Discussion section (on github), does the portion on failures >> need to contain more information about how a failure should be handled in >> TLS? Should a decrypt_error alert be sent? >> >> >> >>

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

There was a push to change the parsing logic for ML-KEM public keys to never fail, by silently reducing, without changing the hash of the public key. I am not sure if NIST ended up adopting that change for their final standard (I hope they did, I think it's the best way to handle this problem),

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

I do not believe that "decode_error" would be the correct alert. As the text currently says: *Failures* Some post-quantum key exchange algorithms, including ML-KEM, have non-zero probability of failure, meaning two honest parties may derive different shared secrets. This would cause a

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

(not speaking as a chair of anything here) The IETF, together with the IRTF, needs to make an independent judgement on whether using PQ-only algorithms is advisable, and if we do not think so, then we should not standardize them, regardless of what CNSA 2.0 requires. The supported groups

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

es need to be >>>> re-evaluated? As an example, for IKEv2, RFC 9370 changes the name of >>>> Transform Type 4 from Diffie-Hellman Group to Key Exchange Method in order >>>> to accommodate QR KEMs. >>>> >>>> >>>> >>>>

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

PM *To:* TLS@ietf.org *Subject:* [TLS] ML-KEM key agreement for TLS 1.3 I have uploaded a preliminary version of ML-KEM for TLS 1.3 <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/>  and have a mo

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

n the > first sentence on datatracker; in the first sentence of Binding properties > on github)? It is not used in RFC 8446 so it might be worth explaining the > meaning or using different phrasing in this sentence. > > > > Also, what are the WG's thoughts on including standalone PQ

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

ion on failures >>> need to contain more information about how a failure should be handled in >>> TLS? Should a decrypt_error alert be sent? >>> >>> >>> >>> 5. In Section 4 (or Security Considerations on github), this may be a >>&g

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

ithub), this may be a >> silly question, but is the definition of "commits" well-understood (in the >> first sentence on datatracker; in the first sentence of Binding properties >> on github)? It is not used in RFC 8446 so it might be worth explaining the >> m

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

s thoughts on including standalone PQC signatures in > the same draft? > > > > Thanks in advance! > > > > Rebecca > > > > Rebecca Guthrie > > she/her > > Center for Cybersecurity Standards (CCSS) > > Cybersecurity Collaboration Center (CCC) &

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

ecca Rebecca Guthrie she/her Center for Cybersecurity Standards (CCSS) Cybersecurity Collaboration Center (CCC) National Security Agency (NSA) From: TLS On Behalf Of Deirdre Connolly Sent: Tuesday, March 5, 2024 9:15 PM To: TLS@ietf.org Subject: [TLS] ML-KEM key agreement for TLS 1.3 I have uploaded a p

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

Bas Westerbaan writes: > We think it's worth it now, but of course we're not going to keep > hybrids around when the CRQC arrives. I think this comment illustrates an important ambiguity in the "CRQC" terminology. Consider the scenario described in the following paragraph from

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

Here's a chart I sent CFRG a few weeks ago of recent claims regarding the exponent, including memory-access costs, of attacks against the most famous lattice problem, namely the "shortest-vector problem" (SVP): * November 2023: 0.396, and then 0.349 after an erratum:

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. Currently the TLS designated experts really only look at the request itself,

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

On Thu, Mar 7, 2024 at 1:47 AM Dennis Jackson wrote: > On 07/03/2024 03:57, Bas Westerbaan wrote: > > We think it's worth it now, but of course we're not going to keep hybrids > around when the CRQC arrives. > > Sure, but for now we gain substantial security margin* against > implementation

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

On 07/03/2024 03:57, Bas Westerbaan wrote: We think it's worth it now, but of course we're not going to keep hybrids around when the CRQC arrives. Sure, but for now we gain substantial security margin* against implementation mistakes, advances in cryptography, etc. On the perf/cost side,

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

-apple-airdrop-users-chinese-authorities-claim-to-do-just-that/ Cheers, John Preuß Mattsson From: TLS on behalf of Ilari Liusvaara Date: Wednesday, 6 March 2024 at 17:46 To: TLS@ietf.org Subject: Re: [TLS] ML-KEM key agreement for TLS 1.3 On Wed, Mar 06, 2024 at 04:25:16PM +, John Mattsson

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

esterbaan , TLS@ietf.org Subject: 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 softw

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

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

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

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

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

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

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

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 >>

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+.

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

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

/o0ukef> > -- > *From:* TLS on behalf of John Mattsson > > *Sent:* Wednesday, March 6, 2024 4:57:10 PM > *To:* Deirdre Connolly > *Cc:* TLS@ietf.org > *Subject:* Re: [TLS] ML-KEM key agreement for TLS 1.3 > > > Thanks Deirdre, > >

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

half of Eric Rescorla < > e...@rtfm.com> > *Date: *Wednesday, 6 March 2024 at 16:12 > *To: *Deirdre Connolly > *Cc: *TLS@ietf.org > *Subject: *Re: [TLS] ML-KEM key agreement for TLS 1.3 > > Deirdre, thanks for submitting this. Can you say what the motivation is >

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

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

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

arch 6, 2024 4:57:10 PM To: Deirdre Connolly Cc: TLS@ietf.org Subject: 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 rig

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

eers, John From: TLS on behalf of Eric Rescorla Date: Wednesday, 6 March 2024 at 16:12 To: Deirdre Connolly Cc: TLS@ietf.org Subject: 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

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

> > I would treat non-hybrid drafts in IETF the same way > as "export" options in code: they're security risks. I would encourage > explicit withdrawal of any such drafts. Does this point apply in your opinion to hash-based signatures? ___ TLS mailing

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

The security analysis of post-quantum crypto is far less mature than the security analysis of ECC was when the Internet moved to ECC: * 48% of the 69 round-1 submissions to the NIST post-quantum competition in 2017 have been broken by now. * 25% of the 48 submissions unbroken during

[TLS] ML-KEM key agreement for TLS 1.3

I have uploaded a preliminary version of ML-KEM for TLS 1.3 and have a more fleshed out version to be uploaded when datatracker opens. It is a straightforward new