Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

Dennis beat me to making the key point about identity :) There are cases where identity misbinding is possible in similar systems. RFC 8844 describes one such case. However, this is not an inherent failing in TLS, but in the usage context. That weakness was not the result of using raw public

[TLS] [Errata Held for Document Update] RFC8446 (5717)

The following errata report has been held for document update for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid5717 --

[TLS] [Errata Held for Document Update] RFC8446 (6204)

The following errata report has been held for document update for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6204 --

[TLS] [Errata Verified] RFC8446 (6139)

The following errata report has been verified for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6139 -- Status: Verified

[TLS] [Errata Verified] RFC8446 (7250)

The following errata report has been verified for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7250 -- Status: Verified

[TLS] [Errata Verified] RFC8446 (7303)

The following errata report has been verified for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid7303 -- Status: Verified

[TLS] [Errata Verified] RFC8446 (6123)

The following errata report has been verified for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6123 -- Status: Verified

[TLS] [Errata Verified] RFC8446 (5483)

The following errata report has been verified for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid5483 -- Status: Verified

[TLS] [Errata Held for Document Update] RFC8446 (6401)

The following errata report has been held for document update for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid6401 --

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

On Fri, Mar 29, 2024 at 2:59 AM David Benjamin wrote: > Regarding renaming, I'm torn. "Group" was a truly horrible rename. The names > we pick make their way into APIs and even sometimes UI surfaces for > developers. Every time I've plumbed TLS named groups into another system, > I've been

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

I don't believe we need a separate range, just to unmark the elliptic curve range. TLS does not usually ascribe meaning to ranges of codepoints because TLS implementations do not need to categorize codepoints they don't understand. The only reason supported groups was partitioned was because of a

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

Sean: I observe that ML-KEM is not a Elliptic curve group or a Finite Field Diffie-Hellman group. I really think we want to include sepport for KEMs. but a separate range is needed. I assume it will be carved out of the Elliptic curve group range. KEMs are not "key agreement" algorithms as

Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

Hi John, It depends what you mean by an identity. TLS1.3 ensures the peers agree on the used RPKs and it doesn't rely on any external proof of possession to achieve that property. How the peers come to trust the RPKs or their corresponding identity is of necessity left to the application -

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

Clarification: I agree on the need to rename the group space. However, I don't support using only mlkem as a curve for tls. However, mlkem as a hybrid makes sense. On Thu, Mar 28, 2024, 20:28 Loganaden Velvindron wrote: > Agreed. > > On Thu, Mar 28, 2024, 19:50 Salz, Rich > wrote: > >> > we

Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

On Thu, Mar 28, 2024 at 03:22:05PM +, John Mattsson wrote: > I looked into what RFC 8446(bis) says about Raw Public Keys. As > correctly stated in RFC 8446, TLS 1.3 with signatures and certificates > is an implementation of SIGMA-I: Assuming certificates are issued with strong assurance,

Re: [TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

On Thu, Mar 28, 2024 at 4:22 PM John Mattsson wrote: > Hi, > > > > I looked into what RFC 8446(bis) says about Raw Public Keys. As correctly > stated in RFC 8446, TLS 1.3 with signatures and certificates is an > implementation of SIGMA-I: > > > > SIGMA does however require that the identities of

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

Agreed. On Thu, Mar 28, 2024, 19:50 Salz, Rich wrote: > > we should really replace the “Elliptic curve groups” note in the 0-255, > 512-65535 range row with something else. I am open to suggestions, but > would like to propose “unallocated”. > > Short and to the point; +1 > > The only

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

+1 to removing the "Elliptic curve groups" note. That partition came out of RFC 7919's (unfortunate ) decision to repurpose the existing DHE cipher suites (see RFC 7919, section 4), so we're stuck treating 256-511 as special.

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

> we should really replace the “Elliptic curve groups” note in the 0-255, > 512-65535 range row with something else. I am open to suggestions, but would > like to propose “unallocated”. Short and to the point; +1 The only alternative I can see is constantly adding things, and eventually we

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

Hi, It would actually be good to change the name of the registry from “Supported Groups” as the new PQC key exchange algorithms are not groups. Cheers, John Preuß Mattsson From: TLS on behalf of Sean Turner Date: Thursday, 28 March 2024 at 15:53 To: TLS List Subject: [TLS] -draft8447bis:

[TLS] TLS 1.3, Raw Public Keys, and Misbinding Attacks

Hi, I looked into what RFC 8446(bis) says about Raw Public Keys. As correctly stated in RFC 8446, TLS 1.3 with signatures and certificates is an implementation of SIGMA-I: SIGMA does however require that the identities of the endpoints (called A and B in [SIGMA]) are included in the messages.

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

**WARNING: Potential bikeshed** -connolly-tls-mlkem-key-agreement has suggested that code points for the NIST PQ be registered in the TLS Supported Groups IANA registry [1]. Currently [2], the registry is carved up into three blocks as follows: Range: 0-255, 512-65535 Registration

Re: [TLS] Working Group Last Call for SSLKEYLOG File

Minor suggestion to refer to -rfc84446bis: https://github.com/tlswg/sslkeylogfile/pull/8 aka let’s make a cluster! spt > On Mar 12, 2024, at 10:57, Sean Turner wrote: > > This is the working group last call for the SSLKEYLOGFILE Format for TLS > Internet-Draft [1]. Please indicate if you

Re: [TLS] Working Group Last Call for SSLKEYLOG File

Just a reminder that this WGLC ends soon! spt > On Mar 12, 2024, at 10:57, Sean Turner wrote: > > This is the working group last call for the SSLKEYLOGFILE Format for TLS > Internet-Draft [1]. Please indicate if you think the I-D is ready to progress > to the IESG and send any comments to

Re: [TLS] Working Group Last Call for ECH

Just a reminder that this WGLC ends soon! spt > On Mar 11, 2024, at 18:00, Joseph Salowey wrote: > > This is the working group last call for TLS Encrypted Client Hello [1]. > Please indicate if you think the draft is ready to progress to the IESG and > send any comments to the list by 31

Re: [TLS] I-D Action: draft-ietf-tls-svcb-ech-01.txt

On 3/28/24 04:37, internet-dra...@ietf.org wrote: Internet-Draft draft-ietf-tls-svcb-ech-01.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings Authors: Ben Schwartz