[TLS] Errata 4800

https://www.rfc-editor.org/errata/eid4800 RFC 5077 , "Transport Layer Security (TLS) Session Resumption without Server-Side State", January 2008 I'm working through the list of errata and came across this one. This mechanism is obsol

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

On Fri, Mar 07, 2025 at 09:00:50AM +, Kris Kwiatkowski wrote: > Indeed, that's very nice. I'm actually running OpenSSL built from a branch > vduc/hybrids on my server > and X25519MLKEM768 seems to work alright. Support for the hybrids has been in the "master" branch since Feb 14th, but prefer

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

On Fri, Mar 07, 2025 at 08:49:37AM +, John Mattsson wrote: > >Similarly, the most preferred sigalgs are ML-DSA-65, ML-DSA-87, and > >ML-DSA-44. Of course these don't take effect unless the server is > >actually configured with a key+cert of that type. > > How does negotiation of ML-DSA work

[TLS] AD review draft-ietf-tls-rfc8447bis-10

AD review of draft-ietf-tls-rfc8447bis-10 I have some comments and small change requests. Do let me know if I got it wrong. Section 3 Setting a value to "Y" or "D" in the "Recommended" column requires IETF Standards Action [RFC8126]. Any state transition to or from a "Y"

[TLS] Re: [Wimse] Public side meetings on identity crisis in attested TLS for Confidential Computing

Hi John, On 06.03.25 14:24, John Kemp wrote: The title of this email is quite alarming to me ("identity crisis") and yet I'm not able to understand what the actual issue is other than someone wishing to replace public-key authentication with "attestation". The announcement was not supposed to /

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

Thanks. Sounds real good. On 07/03/2025 10:22, Tim Hudson wrote: On Fri, Mar 7, 2025 at 7:01 PM Kris Kwiatkowski wrote: May I know if you have a plan for FIPS certificaton for PQC after release? Absolutely - OpenSSL-3.5 will be heading into a fresh FIPS140-3 validation in April once the

[TLS] Dnsdir last call review of draft-ietf-tls-esni-23

Reviewer: R. Gieben Review result: Ready with Nits Hello, I'm the designated reviewer from dnsdir and I've reviewed -23. I have a bunch of nits and minor questions, but section 10.2 stood out as I had trouble understanding the DNS bits in there. Though I think that those can be fairly easy be fi

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

>Yes, not only enabled, but preferred, with servers sending an HRR when a >client reports support for X25519MLKEM768, but does not send a >corresponding keyshare. That is truly excellent news! Thank you! >Similarly, the most preferred sigalgs are ML-DSA-65, ML-DSA-87, and >ML-DSA-44. Of course t

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

Indeed, that's very nice. I'm actually running OpenSSL built from a branch vduc/hybrids on my server and X25519MLKEM768 seems to work alright. May I know if you have a plan for FIPS certificaton for PQC after release? Cheers, Kris On 07/03/2025 04:02, Viktor Dukhovni wrote: On Thu, Mar 06, 20

[TLS] Re: AD review draft-ietf-tls-rfc8447bis-10

> On Mar 6, 2025, at 9:33 PM, Paul Wouters > wrote: > > AD review of draft-ietf-tls-rfc8447bis-10 > > I have some comments and small change requests. Do let me know if I got it > wrong. Will do. BTW - one choice for you below. > Section 3 > > Setting a value to "Y" or "D" in the

[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