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

> 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: [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]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]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]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]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: 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] 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

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

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

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

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

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

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

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

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

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

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

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

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

[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

[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

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

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

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

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

[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] 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.

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