Re: [TLS] sect571r1

> So, should it stay or should it go now? Opinions? > +1 that sect571r1 be removed. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Early code point assignment request for curve25519 and curve448

On Nov 14, 2015 2:18 PM, "Eric Rescorla" wrote: > I'm fine either way. As Adam says, it wouldn't be harmful to wait for > the signature code point assignments for a bit, but I doubt it would > be that harmful not to. People who deploy the signature schemes > before they are stable do so at their o

Re: [TLS] NIST on addressing visibility challenges with TLS 1.3

👀 On Tue, Sep 28, 2021, 12:54 PM Salz, Rich wrote: > This will be of interest to some on this list. Quoting: “The NCCoE at > NIST recognizes the challenges associated with compliance, operations, and > security when enterprises employ encrypted protocols, in particular > Transport Layer Securit

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

https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-xyber768d00-03 defines the `X25519Kyber768Draft00` `NamedGroup` as 0x6399 https://datatracker.ietf.org/doc/html/draft-kwiatkowski-tls-ecdhe-kyber-01 defines the `SecP256r1Kyber768Draft00` `NamedGroup` as 0x639A On Mon, Nov 6, 2023 at 11:4

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

There are several documents in a cluster that define new hybrid `NamedGroup`s and how those operate / are combined, abstracted away from the rest of the TLS handshake. Treating hybrid schemes (key establishment, signatures) as /separate and distinct from their component algorithms/ is a good idea.

[TLS] Clarifying generating key exchange values for hybrid key_change in draft-ietf-tls-hybrid-design

Hey there TLSWG ✨ I have opened a PR to make explicit the supported mechanisms for generating ephemeral keys in hybrid TLS 1.3 key exchanges, especially where the component algorithms of the hybrid `NamedGroup` may also be supported as their own `NamedGroup`s in a `ClientHello`, and how to share (

Re: [TLS] TLS chair update: Deirdre Connolly replacing Christopher Wood

airs. This also prevents ossification of WGs :) > > Christopher Wood has stepped down as TLS WG chair and Deirdre Connolly has > stepped up to replace him. Thanks to Chris for all his work and welcome to > Deirdre! > > Paul > ___ >

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

At least one bit of work: https://dl.acm.org/doi/abs/10.1145/3548606.3559360 On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla wrote: > What do we have in terms of formal analysis for this extension? > > -Ekr > > > On Fri, Dec 1, 2023 at 11:40 AM Russ Housley wrote: > >> I think this should move forwa

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

Whoops wrong one, strike that On Sun, Dec 3, 2023, 3:28 PM Deirdre Connolly wrote: > At least one bit of work: > https://dl.acm.org/doi/abs/10.1145/3548606.3559360 > > On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla wrote: > >> What do we have in terms of formal analys

[TLS] Adoption call for 'TLS 1.2 Feature Freeze'

At the TLS meeting at IETF 118 there was significant support for the draft 'TLS 1.2 is in Feature Freeze' ( https://datatracker.ietf.org/doc/draft-rsalz-tls-tls12-frozen/) This call is to confirm this on the list. Please indicate if you support the adoption of this draft and are willing to review

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

Hi all, Thanks to everyone who chimed in on this adoption call. It looks like there is consensus to adopt this as a WG item and volunteers to help review. Rich, can you please submit draft-ietf-tls-tls12-frozen-00 to datatracker, and transfer the GitHub repo to the tlswg GitHub org? Thank you! Ch

Re: [TLS] [CFRG] X-Wing: the go-to PQ/T hybrid KEM?

should be adjusted so that X-Wing is the obvious > instantiation for ML-KEM + X25519. > > > > Aside: do you have an opinion about fixedInfo as a prefix vs a suffix? We > chose suffix simply because it more obviously aligns with SP 800-56Cr2, and > we’ve all had the experience

[TLS] Proposal: a TLS formal analysis triage panel

A few weeks ago, we ran a WGLC on 8773bis, but it basically came up blocked because of a lack of formal analysis of the proposed changes. The working group seems to be in general agreement that any changes to TLS 1.3 should not degrade or violate the existing formal analyses and proven security pro

[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

Re: [TLS] Proposal: a TLS formal analysis triage panel

7;t > find the extension at hand interesting enough, they're volunteering to help > so I wouldn't blame them for picking what they want to work on.) In that > hypothetical scenario, does the document proceed without formal analysis, > or is it blocked? > > Thanks, > David

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

ybrid-design. On Wed, Mar 6, 2024 at 10:12 AM Eric Rescorla wrote: > 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 Deir

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

as a NamedGroup. > > > > I don't understand. We align with hybrid by not being hybrid? > > > > - encapsulated shared secret ciphertext > > > > Maybe shared secret encapsulated in the ciphertext? > > > > Cheers, > > John > > > > *Fr

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

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

ure PQ clear in mind, and taken seriously. On Wed, Mar 6, 2024 at 12:21 PM 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? >&

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

ated experts of the IANA registry. > > Best, > > Bas > > > On Wed, Mar 6, 2024 at 3:16 AM Deirdre Connolly > wrote: > >> I have uploaded a preliminary version of ML-KEM for TLS 1.3 >> <https://datatracker.ietf.org/doc/draft-connolly-tls-mlkem-key-agreement/>

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

[TLS] Time to first byte vs time to last byte

"At the 2024 Workshop on Measurements, Attacks, and Defenses for the Web (MADweb), we presented a paper¹ advocating time to last byte (TTLB) as a metric for assessing the total impact of data-heavy, quantum-resistant algorithms such as ML-KEM and ML-DSA on real-world TLS 1.3 connections. Our paper

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

nature are orthogonal concepts, and it will be easier to review if they > are kept in separate documents. > > -Ekr > > >> >> >> >> *From:* TLS *On Behalf Of *Deirdre Connolly >> *Sent:* Tuesday, March 5, 2024 9:15 PM >> *To:* TLS@ietf.or

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

In Section 4 (or Security Considerations on github), 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

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

opinion. On Wed, Mar 13, 2024 at 9: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 &g

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

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 > meaning or using different phrasing in this sentence.

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

ivial user base for such an option very soon. On Thu, Mar 14, 2024 at 7:34 AM Dennis Jackson wrote: > On 14/03/2024 01:41, Deirdre Connolly wrote: > > Oh and one more consideration: hybrid brings complexity, and presenting > the pure-PQ solutions and their strictly lesser compl

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

13, 2024, 10:08 PM Deirdre Connolly wrote: > Thank you very much for the notes! > > A few specific comments: > > > >> 1. In Section 1.1 (or Introduction - Motivation in the github version), I >> would suggest that the second sentence ("Having a fully post-qua

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

sit that aren't >> caught by a CRC or other check are more likely than ML-KEM decapsulation >> failures. Since the two are indistinguishable to the client, the client >> would have to handle them in the same way. So, I would suggest either >> omitting this paragraph o

Re: [TLS] Proposal: a TLS formal analysis triage panel

pv > > [2] https://github.com/Inria-Prosecco/reftls/issues/6 > > [3] https://github.com/Inria-Prosecco/reftls/issues/7 > > [4] https://github.com/lurk-t/proverif > > [5] https://mailarchive.ietf.org/arch/msg/tls/ZGmyHwTYh2iPwPrirj_rkSTYhDo/ > On 06.03.24 02:37, Deirdre Conn

Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space

> KEMs are not "key agreement" algorithms as suggested by this draft name. In a key agreement algorithm, both parties contribute to the shared secret. With a KEM, only one party generates the the shared secreat value. This is not generally accurate with the KEM schemes under consideration for ado

[TLS] Kicking off the TLS 1.3 formal analysis triage panel

Hello everyone! We're kicking off our TLS 1.3 formal analysis triage panel. We have these volunteers participating: - Douglas Stebila - Dennis Jackson - Franziskus Kiefer - Cas Cremers - Karthikeyan Bhargavan - Vincent Cheval Some of them are on this list, some are not, major welcomes and thank

[TLS]Re: Kicking off the TLS 1.3 formal analysis triage panel

t to express major thanks to our triage panel for their participation and expertise here! Now it's up to WG to discuss what to do with this analysis. 😁 Cheers, Deirdre, for the chairs On Thu, Apr 18, 2024 at 11:36 AM Deirdre Connolly wrote: > Hello everyone! We're kicking off our TL

[TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt

Not a direct reference for TLS 1.3, but recent related work from the document author, Douglas's analysis of PQ3 iMessage¹, has a hybrid encrypted session setup with commonalities with the TLS 1.3 key schedule, especially the layers of calls to HKDF.Expand and HKDF.extract, albeit in a different ord

[TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt

both cases we are deviating from the idealised PRF-ODH > setting so this does not contradict the proof that StDH implies PRF-ODH ( > https://ia.cr/2017/517). > > > > Peter > > > > *From:* Deirdre Connolly > *Sent:* Wednesday, July 24, 2024 3:34 PM > *To:* Peter

[TLS]Meta deploying -hybrid-design

Starting with internal connections: https://engineering.fb.com/2024/05/22/security/post-quantum-readiness-tls-pqr-meta/ > For our deployment, we have chosen Kyber with X25519 in a hybrid setting. Kyber is the only key encapsulation mechanism selected by NIST for standardization so far. Kyber come

[TLS]Working Group Last Call for "Hybrid key exchange in TLS 1.3"

This email starts the working group last call for the Internet-Draft "Hybrid key exchange in TLS 1.3", located here: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ The WG last call will end 26th August 2024 @ 2359 UTC. Please review the draft and submit issues and pull requests v

[TLS]Re: [EXTERNAL] Re: Working Group Last Call for "Hybrid key exchange in TLS 1.3"

Yes, there are backwards-incompatible changes including domain-separating key material by parameter set. On Wed, Aug 14, 2024, 10:07 AM Salz, Rich wrote: > ZjQcmQRYFpfptBannerEnd > > I think it would make sense to get new code points for hybrids based on > the final ML-KEM spec, so that implemen

[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement

> Anonymous reviewers have a number of problems The current triage panel is not anonymous, and the feedback they gave on RFC8773bis included the complete input from all current members. On Sun, Aug 25, 2024 at 4:51 PM Bob Beck wrote: > > > On Aug 25, 2024, at 13:56, Salz, Rich > wrote: > > 

[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement

> I think if this is truly a problem it is symptomatic to participation in a working group as a whole and should be addressed across the board for everyone. I agree that it is a problem and should be addressed across the IETF. Unfortunately we keep making changes to TLS 1.3 in the meantime, so. I

[TLS]Re: Consensus call for RFC8773bis Formal Analysis Requirement

All of it was posted to the list in May: https://mailarchive.ietf.org/arch/msg/tls/vK2N0vr83W6YlBQMIaVr9TeHzu4/ On Mon, Aug 26, 2024, 9:22 AM Salz, Rich wrote: > The current triage panel is not anonymous, and the feedback they gave > on RFC8773bis included the complete input from all current me

[TLS] Re: FATT membership

Yes we need to do this. On Mon, Oct 21, 2024, 1:44 PM Salz, Rich wrote: > I just watched the video and was taken aback that on an interim about the > FATT process, neither Sean nor Dierdre knew how big it was, let alone who > the members are, although “a couple of suggestions have been received.

[TLS] Re: TLS WG Interim summary (was Re: TLS WG Virtual Interim on FATT Process)

Ah if that's an overloaded term we can use another word On Mon, Oct 21, 2024, 3:55 PM Stephen Farrell wrote: > > > On 21/10/2024 20:50, Deirdre Connolly wrote: > > The proposal discussed at the interim involves the Liaison role > > OK, I'll wait to see the minu

[TLS] Re: TLS WG Interim summary (was Re: TLS WG Virtual Interim on FATT Process)

rom 20 years ago :D On Mon, Oct 21, 2024 at 4:53 PM Rob Sayre wrote: > On Mon, Oct 21, 2024 at 1:46 PM Deirdre Connolly > wrote: > >> Those guidelines may be useful to us, thanks for the link. >> >> I want to be clear that the output of the FATT is not 'design&

[TLS] Re: TLS WG Interim summary (was Re: TLS WG Virtual Interim on FATT Process)

ccount for future drafts of the document (or not!), so would the FATT be providing input, but not necessarily 'design'. On Mon, Oct 21, 2024 at 4:31 PM Rob Sayre wrote: > On Mon, Oct 21, 2024 at 1:14 PM Deirdre Connolly > wrote: > >> Ah if that's an overloaded term we

[TLS] Re: TLS WG Interim summary (was Re: TLS WG Virtual Interim on FATT Process)

> Here is a summary across all participants"). Yes, the whole FATT at that time participated > if the WG consensus is to not take the advice of the panel, then that will be part of the shepherd writeup, including an explanation. If during the work of the working group for a document we got a tr

[TLS] Re: TLS WG Interim summary (was Re: TLS WG Virtual Interim on FATT Process)

All discourse between the FATT and the WG has names attached, including what has happened already. All decisions about how to block, evolve, last call, whatever is up to working group consensus. On Mon, Oct 21, 2024, 3:09 PM Stephen Farrell wrote: > > Hiya, > > On 21/10/2024 18:43, Salz, Rich w

[TLS] Re: TLS WG Interim summary (was Re: TLS WG Virtual Interim on FATT Process)

anything with FATT feedback at all. This goal is always to solicit rigorous analysis as input to regular working group consensus activity On Mon, Oct 21, 2024, 3:42 PM Stephen Farrell wrote: > > > On 21/10/2024 20:37, Deirdre Connolly wrote: > > Yes, the updated proposal at the interi

[TLS] Re: TLS WG Interim summary (was Re: TLS WG Virtual Interim on FATT Process)

:34 PM Stephen Farrell wrote: > > > On 21/10/2024 20:28, Deirdre Connolly wrote: > > All discourse between the FATT and the WG has names attached, including > > what has happened already. > > Earlier Joe said: > > "The current structure of the FATT does not all

[TLS] WG Last Call for draft-ietf-tls-rfc8447bis, "IANA Registry Updates for TLS and DTLS”

This email starts the working group last call for "IANA Registry Updates for TLS and DTLS” I-D, located here: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/ The WG Last Call will end Wednesday October 30th 2024 @ 2359 UTC. Please review the I-D and submit issues and pull requests vi

[TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02

So it's pretty clear that TLS 1.3 is FIPS-able, because it has been validated multiple times. But it's not just a blessed exception, or that FIPS is 'not sensitive' to the particulars - it looks to be using HKDF in compliance with SP 800-133rev2 (Section 6.3 Option #3), SP 800-56Crev2, and SP 800-1

[TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02

It would in fact be great to get an official answer on whether either order is FIPS-compatible, as it clear that the order doesn't matter for security when used in TLS 1.3 as written in tls-hybrid-design (fixed lengths, everything public is going into the key schedule anyway, etc). There are other

[TLS] Re: X25519MLKEM768 in draft-kwiatkowski-tls-ecdhe-mlkem-02

Just to clarify Kris, you are _asking_ if there is a plan? I don't know if Quynh can comment but NIST have said publicly that they plan to clarify hybrid KEMs in the forthcoming SP 800-227: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/6_D0mMSYJZY/m/3DwwIAJXAwAJ > is there a plan to cha

[TLS] Re: ML-DSA in TLS

> > Unfortunately, the mechanism to combine the two signatures can also > fail, and its failure can end up totally undermining security. > So it is not just pure backup. Yes. I don't agree with composite signatures being slightly more complicated. > I think that composite signatures are much mo

[TLS] Re: ML-DSA in TLS

> Today for the WebPKI there is no security benefit to enabling post-quantum certificates (in stark contrast with post-quantum key agreement.) On the other hand, there is a big cost with extra bytes on the wire. As it stands, we do not intend to enable post-quantum certificates by default before th

[TLS] Fwd: New Version Notification for draft-connolly-tls-mlkem-key-agreement-04.txt

24 at 4:08 PM Subject: New Version Notification for draft-connolly-tls-mlkem-key-agreement-04.txt To: Deirdre Connolly A new version of Internet-Draft draft-connolly-tls-mlkem-key-agreement-04.txt has been successfully submitted by Deirdre Connolly and posted to the IETF repository. Name:

[TLS] Re: draft-connolly-tls-mlkem-key-agreement-03 and IANA IDs

very thrilled about the prospect. > > See also > https://mailarchive.ietf.org/arch/msg/tls/-jYbYd7cXKIzySPp578kAsWZt5c/ > > David > > On Fri, Nov 1, 2024 at 12:28 PM Deirdre Connolly > wrote: > >> If there's a choice to be made I favor the 512 513 514 choic

[TLS] Re: draft-connolly-tls-mlkem-key-agreement-03 and IANA IDs

Ah, oops! Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but of course it's not a group, it's a KEM scheme over which no Diffie-Hellman of any kind can be done. Where do IANA preallocations start bumping up against "well we're doing something completely different anyway"? O

[TLS] Re: draft-connolly-tls-mlkem-key-agreement-03 and IANA IDs

If there's a choice to be made I favor the 512 513 514 choices On Fri, Nov 1, 2024, 12:20 PM Deirdre Connolly wrote: > Ah, oops! > > Tangentially, this is registering a `NamedGroup` / `SupportedGroup`, but > of course it's not a group, it's a KEM scheme over which

[TLS] Re: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

Two meetings ago there was a consistent vibe in the room that Recommend'ing any PQ parameters, hybrid or no, was premature; has that changed? On Mon, Nov 11, 2024 at 9:00 AM Alicja Kario wrote: > On Sunday, 10 November 2024 13:38:38 CET, Kris Kwiatkowski wrote: > > Hello, > > > > As discussed du

[TLS] Re: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

OK; what about ML-KEM only? On Mon, Nov 11, 2024, 9:58 AM Bas Westerbaan wrote: > That was before the release of FIPS 203. > > On Mon, 11 Nov 2024 at 18:29, Deirdre Connolly > wrote: > >> Two meetings ago there was a consistent vibe in the room that >> Recommend&#x

[TLS] Re: ML-DSA in TLS

I would rather have a separate I-D for anything beyond ML-DSA (and thanks, this is great!) On Wed, Oct 23, 2024 at 2:13 PM Alicja Kario wrote: > On Wednesday, 23 October 2024 20:01:28 CEST, John Mattsson wrote: > > Let’s have an adoption call asap. > > > > I made some minor suggestions > > https

[TLS] Re: [DNSOP] AD review draft-ietf-tls-svcb-ech

> We could add a recommendation like "Clients using ECH SHOULD select a DNS resolver that they trust to preserve the confidentiality of their queries and return authentic answers, and communicate using an authenticated and confidential transport", but this draft seems like an odd place for that tex

[TLS] Re: [DNSOP] AD review draft-ietf-tls-svcb-ech

> I do not, however, think that we should have a SHOULD for using DNSSEC as it would be more in the nature of a RFC 6919 "MUST (BUT WE KNOW YOU WON'T)". I agree On Mon, Sep 30, 2024 at 6:43 AM Eric Rescorla wrote: > > > > On Sun, Sep 29, 2024 at 7:34 PM Paul Wouters 40aiven...@dmarc.ietf.org>

[TLS] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction

> We should reap what we sow and just use supported_groups Agreed 🥲 On Wed, Sep 25, 2024 at 10:54 AM Bob Beck wrote: > > > On Tue, Sep 24, 2024 at 5:12 PM David Benjamin > wrote: > >> I should add, another reason to call it tls-supported-groups is that this >> is essentially what the server wo

[TLS] Re: Fwd: New Version Notification for draft-connolly-tls-mlkem-key-agreement-04.txt

> > > OLD: "ML-KEM has a cryptographically small failure rate" > > NEW: "ML-KEM has a cryptographically small failure rate less than 2^-138" > > > > > https://github.com/dconnolly/draft-connolly-tls-mlkem-key-agreement/pull/5/files > > > > Cheers, > &

[TLS] Re: ML-DSA in TLS

The CNSA 2.0 FAQ states, "Do not use a hybrid or other non-standardized QR solution on NSS mission systems except for those exceptions NSA specifically recommends to meet standardization or interoperability requirements", and, "because NSA is confident that CNSA 2.0 algorithms will sufficiently pr

[TLS] Re: ML-DSA in TLS

(and AES-256-GCM) On Tue, Nov 19, 2024, 5:11 PM Deirdre Connolly wrote: > > In other words, does CNSA 2.0 tolerate ECC, by effectively ignoring its > presence, or not? > > From > https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-00.html: > > "I

[TLS] Re: ML-DSA in TLS

NSA 2.0 >> (other than where required due to protocol constraints, such as during key >> establishment in IKEv2 as pointed out earlier in this thread). As such, our >> CNSA 2.0 TLS profile requires only standalone ML-KEM-1024, and ML-DSA-87; >> we recently posted an early

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

Pursuant to this thread, preliminary support for MLKEM768-only has been merged into rustls (I contributed): https://github.com/rustls/rustls/pull/2259 On Thu, Dec 5, 2024 at 4:10 PM Scott Fluhrer (sfluhrer) wrote: > How do we proceed with this draft? > > > > This draft is quite boring (which is

[TLS] Re: Trust Anchor IDs and PQ

> I think HSTS provides the basis for a more effective solution. It needs only to be extended with a single additional bit ("Enforce use of PQ signatures") and it's already well-understood by website operators. Managing the preload list is a bit unpleasant for browsers, but strictly speaking the pr

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

> The _proposed_ rubber-stamping is to let NSA buy TLS WG endorsement of this spec. No. I proposed this document because I want to be able to negotiate PQ-only key establishment without hybrid. It got codepoints and now is getting more support, which is nice. I wrote it because I wanted to use it.

[TLS] Re: draft-connolly-tls-mlkem-key-agreement

> Hence, Cisco will implement it; I am essentially just asking for code points. Code points have been allocated: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 https://www.ietf.org/archive/id/draft-connolly-tls-mlkem-key-agreement-05.html#name-iana-consid

[TLS] Re: WG Adoption Call for Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3

Discussed in this thread started December 16th: https://mailarchive.ietf.org/arch/msg/tls/yGZV5dBTcxHJhG-JtfaP6beTd68/ On Wed, Feb 26, 2025 at 2:46 PM Christopher Wood wrote: > As I understand it, the purpose of this draft is to specify an > interoperable key exchange mechanism that we can depl

[TLS] Re: ML-KEM IANA and draft-connolly-tls-mlkem-key-agreement codepoint and inconsistencies

This is great news On Thu, Mar 6, 2025, 11:05 PM Viktor Dukhovni wrote: > On Thu, Mar 06, 2025 at 09:01:13PM +0100, Bas Westerbaan wrote: > > > This is indeed fantastic—congratulations! > > > > Will X25519MLKEM768 be enabled by default? > > Yes, not only enabled, but preferred, with servers send

[TLS] Re: NIST on hybrid key exchange

💯 that one too On Thu, Feb 27, 2025, 2:44 PM Kris Kwiatkowski wrote: > Yes, it should be the case once SP800-56C is updated (which is a plan). > See this message: > > https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/ST_yMzYyMl0/m/hFlrkW1CCgAJ > On 27/02/2025 19:05, Salz, Rich wrote: > > I

[TLS] Re: NIST on hybrid key exchange

Yep, the upcoming SP 800-227 draft says that officially, order doesn't matter, at least in terms of the hybrids defined for TLS 1.3: https://doi.org/10.6028/NIST.SP.800-227.ipd I don't know if "anything" hybrid with ML-KEM is theoretically FIPS but it does make things easier. On Thu, Feb 27, 2025

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

The IANA codepoints allocated in the current draft are all 'Recommended: N' On Tue, Apr 1, 2025, 8:59 PM Martin Thomson wrote: > Like other pure ML-KEM uses, I am OK with adoption, though I might oppose > Recommended: Y when it comes to that. I also share John's concerns about > key reuse, but

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

> rather than a safer hybrid As a coauthor on hybrid publications and I-Ds, I do not agree that hybrids are categorically safer. The -tls-hybrid-design for hybrids is pretty great... if you use secure component algorithms. On Wed, Apr 2, 2025, 12:24 PM Bellebaum, Thomas < thomas.belleb...@aisec.f

[TLS] Re: The TLS WG has placed draft-connolly-tls-mlkem-key-agreement in state "Call For Adoption By WG Issued"

> A question to the authors: > The draft talks about "users that need to be fully post-quantum". > Can you please give a specific example of such users and their motivation? A specific example is moving to a compute / dependency base that is minimalist to only PQ primitives they wish to maintain,

[TLS] Publication has been requested for draft-ietf-tls-rfc8447bis-10

Deirdre Connolly has requested publication of draft-ietf-tls-rfc8447bis-10 as Proposed Standard on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/ ___ TLS ma