[TLS] Re: [Ace] IoT certificate profile vs TLS SNI and subjectAltName

On Mon, Jan 6, 2025 at 11:31 AM Michael Richardson wrote: > > Please note and respect the Reply-To: u...@ietf.org. > > 4. Find a sensible way to extend RFC6066 to accomodote other forms of SNI. > There isn't an IANA registry for this. > Just as a technical matter, it's not really possible to ex

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

On Mon, Jan 06, 2025 at 08:00:04AM +, Kris Kwiatkowski wrote: > On 06/01/2025 06:18, Viktor Dukhovni wrote: > > it would be very unlikey to get > > used. > The addition of that codepoint was previously discussed on this mailing > list, and as Victor says, > it is unlikely to be used. Sure, but

[TLS] IoT certificate profile vs TLS SNI and subjectAltName

Please note and respect the Reply-To: u...@ietf.org. TL;DR> Help us avoid stuffing non-DNS strings into SubjectAltName dNSName when doing device to device (D)TLS. In https://github.com/thomas-fossati/draft-tls13-iot/issues/65 I ask why draft-ietf-uta-tls13-iot-profile suggests that IoT de

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

MLKEM1024 is the CNSA 2.0 approved key exchange https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-00.html Yes. secp384r1 is the CNSA 1.0 approved key exchange https://www.rfc-editor.org/rfc/rfc9151.html

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

Didn't CNSA 2 only allow hybrids if there is no alternative? There is a codepoint for MLKEM1024 in TLS now. On Mon, Jan 6, 2025 at 9:57 AM Kris Kwiatkowski wrote: > Sure, but for the record the same applies to SecP3841MLKEM1024 > > > I think the main motivation for ECDH/P-384 is CNSA compliance,

[TLS] Re: [Ace] IoT certificate profile vs TLS SNI and subjectAltName

On Mon, Jan 6, 2025 at 6:14 PM Eric Rescorla wrote: > > > > On Mon, Jan 6, 2025 at 11:31 AM Michael Richardson > wrote: >> >> >> Please note and respect the Reply-To: u...@ietf.org. >> >> >> >> 4. Find a sensible way to extend RFC6066 to accomodote other forms of SNI. >> There isn't an IANA regi

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

Sure, but for the record the same applies to SecP3841MLKEM1024 I think the main motivation for ECDH/P-384 is CNSA compliance, so I don't think it is "the same applies". Yes, it is slower than x25519 or ECDH/p256.___ TLS mailing list -- tls@ietf.org To

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

On 06/01/2025 06:18, Viktor Dukhovni wrote: it would be very unlikey to get used. The addition of that codepoint was previously discussed on this mailing list, and as Victor says, it is unlikely to be used.___ TLS mailing list -- tls@ietf.org To unsub

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

I also have a hard time too see why it is needed. MLKEM1024 is the CNSA 2.0 approved key exchange https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-00.html secp384r1 is the CNSA 1.0 approved key exchange https://www.rfc-editor.org/rfc/rfc9151.html If SecP3841MLKEM1024 is CNSA 1.0 co

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

On Monday, 6 January 2025 11:35:57 CET, John Mattsson wrote: I also have a hard time too see why it is needed. MLKEM1024 is the CNSA 2.0 approved key exchange https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-00.html secp384r1 is the CNSA 1.0 approved key exchange https://www.rfc-e

[TLS] Re: draft-kwiatkowski-tls-ecdhe-mlkem and x448

On Monday, 6 January 2025 09:49:35 CET, Viktor Dukhovni wrote: On Mon, Jan 06, 2025 at 08:00:04AM +, Kris Kwiatkowski wrote: On 06/01/2025 06:18, Viktor Dukhovni wrote: it would be very unlikey to get used. The addition of that codepoint was previously discussed on this mailing list, and a