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

I support adoption, I have already implemented all three methods documented in it. On Wednesday, 26 February 2025 19:26:24 CET, Sean Turner wrote: At IETF 121, the WG discussed “Post-Quantum Hybrid ECDHE-MLKEM Key Agreement for TLSv1.3”; see [0] and [1]. We also had some discussion in an inform

[TLS] Re: [EXTERNAL] 2nd Working Group Last Call for The SSLKEYLOGFILE Formatfor TLS

On Tuesday, 25 February 2025 18:47:33 CET, Andrei Popov wrote: * But I don't know of anywhere else with broad enough remit * to mandate a behavior for all applications using TLS. This is a common perception, and it is exactly why publishing SSLKEYLOGFILE documents in the context of the I

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

During a LAMPS discussion of another ML-KEM draft, I started tracking two BCP 79 compliance issues triggered by the patent situation, with a structured presentation of the arguments and counterarguments: https://cr.yp.to/2025/bcp-79-issues.html As far as I can see, the same considerations app

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

Dan: Your ”issues” did not make sense in LAMPS and they do not make sense in TLS: 1. The draft does not specify anything that is MTI for TLS, (currently it is RECOMMENDED=N) 2. The is no IPR disclosures on the draft, if you want the help the owners of the alleged patent even more, you sh

[TLS] PQC Dialogue with Government Stakeholders Side-Meeting at IETF 122 Bangkok

Hi, There was significant interest from several countries to have a side-meeting on PQC at IETF 122 Bangkok, so Ericsson will organize such a meeting on Monday 17 March 15.15 - 16.45 Bangkok time in Meeting Room 2 [40 seats] (overlapping with Monday Session III). It is possible to attend remote

[TLS] NIST on hybrid key exchange

I thought that I remember (sic) that NIST said that hybrid key exchange, where one was FIPS approved, was still FIPS approved, and further that the order did not matter. Do I remember correctly? And, if so, does that mean “anything” hybrid with MLKEM is FIPS-okay now? ___

[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: Implicit ECH Config for TLS 1.3 – addressing public_name fingerprinting

Hello TLS, After offline conversations about how sever-side trial decryption is implemented, I think this implicit ECH draft can be simplified. Furthermore, it may be possible to make a small change to draft -23 to get most of the benefits of this draft in the main ECH document. Section 7.1 of dr

[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

[TLS] Re: Additional uses for SSLKEYLOGFILE entries

Hi Brian, Stephen, At 06:18 AM 27-02-2025, Stephen Farrell wrote: From my POV yes: fundamentally it is a bad idea for the IETF to standardise ways to exfiltrate keys even if there may be innocuous uses for those. And this latest ask (extending the exfiltration from being a TLS-only thing, to cove

[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: NIST on hybrid key exchange

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 thought that I remember (sic) that NIST said that hybrid key exchange, where on

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

I support adoption of this draft. > Op 26 feb 2025, om 20:16 heeft Christopher Wood het > volgende geschreven: > > As I understand it, the purpose of this draft is to specify an interoperable > key exchange mechanism that we can deploy. The draft already has code points > allocated to it, an

[TLS] Re: Additional uses for SSLKEYLOGFILE entries

Hiya, On 27/02/2025 14:10, Sipos, Brian J. wrote: Is there any fundamental objection to eventually allocating labels specifically for EDHOC use? From my POV yes: fundamentally it is a bad idea for the IETF to standardise ways to exfiltrate keys even if there may be innocuous uses for those.

[TLS] Additional uses for SSLKEYLOGFILE entries

TLS WG, I've been looking into a mechanism to inspect and diagnose behaviors of the EDHOC protocol (RFC 9528) in a way that doesn't require human-in-the-loop between the entities-under-test and the diagnostic tools (e.g. live Wireshark capture). The existing TLS/DTLS dissectors make use of the alm

[TLS] Erik Kline's No Objection on draft-ietf-tls-tls12-frozen-06: (with COMMENT)

Erik Kline has entered the following ballot position for draft-ietf-tls-tls12-frozen-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to h

[TLS] Re: Erik Kline's No Objection on draft-ietf-tls-tls12-frozen-06: (with COMMENT)

### S4 * s/indication indication/indication/ Already fixed in the my editor's copy copy :) ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org