Markdown Version | Transcript | Recording 1 | Recording 2 | Session Materials

Session Date/Time: 16 Mar 2026 03:30

TLS

IETF 125 Session I Minutes

Date: Monday, March 24, 2025 (Meeting 125)
Chairs: Joe Salowey, Deirdre Connolly, Sean Turner (absent)

## Summary

The TLS Working Group held its first of two sessions at IETF 125. The session covered working group status updates, several post-quantum cryptography (PQC) related drafts, and a proposal for PAKE in TLS 1.3. Key topics included the advancement of [draft-ietf-tls-mldsa] toward Working Group Last Call (WGLC), ongoing debates regarding the security considerations and motivation for [draft-ietf-tls-mlkem], and the requirements for formal analysis for [draft-ietf-tls-pake]. A non-working group proposal for PQC rollback resistance (PQ Continuity) was also presented.

## Key Discussion Points

### WG Status and Presentation Updates

Joe Salowey provided an update on the WG status using the TLS Agenda Slides and TLS WG Update.

An appeal regarding the adoption of [draft-ietf-tls-mlkem] was unsuccessful.
Recent RFCs: TLS ECH (RFC 9437), Bootstrapping ECH (RFC 9438), and DTLS 1.3 (RFC 9147) have been published.
[draft-ietf-tls-super-jumbo-record-limit] has completed WGLC; chairs are confirming implementation status (currently one known implementation from Hannes Tschofenig).

### Hollebeek - Use of ML-DSA in TLS 1.3

Tim Hollebeek presented [draft-ietf-tls-mldsa].

The draft registers code points for ML-DSA and prohibits its use in TLS 1.2.
Richard Barnes and Ousama questioned if a dedicated RFC is necessary since code points are registered.
Tim Hollebeek and David Benjamin argued that the draft is necessary to define protocol-specific requirements such as context strings, the use of pure vs. pre-hash forms, and explicitly forbidding TLS 1.2 to guide implementers.
Victor Vasiliev and Eric Rescorla (Ecker) noted a need for technical precision regarding the TLS 1.2 prohibition: specifically, whether it applies only to the TLS protocol signature schemes or if it also restricts ML-DSA in X.509 certificate chains used within a TLS 1.2 connection.

### TLS PAKE

Laura Handly presented updates on [draft-ietf-tls-pake].

Recent changes include specifications for CPace and various clarifications.
Scott Fluhrer noted a missing security consideration: Spake2+ can be broken if a single discrete log problem is solved (e.g., via a slow quantum computer).
Formal Analysis: Laura Handly and Chris Wood are working on a ProVerif model. Ousama and Eric Rescorla emphasized that substantial formal analysis is required before advancement, particularly to verify that the TLS Finished message safely replaces the explicit key confirmation messages required by underlying PAKE specifications.
FAT Process: Tom Ritter clarified that the Formal Analysis Team (FAT) provides opinions to the chairs but is not a "gatekeeper" or part of the formal consensus process.

### ML-KEM for TLS 1.3

Deirdre Connolly presented updates for [draft-ietf-tls-mlkem].

The draft defines ML-KEM-only (non-hybrid) key agreement for TLS 1.3.
Recent updates include normative language forbidding the reuse of randomness in ciphertext generation and updated security considerations regarding IND-CCA properties and hybrid deployment.
Discussion on Motivation: Some participants suggested removing the "Motivation" section to reduce controversy. Victor Vasiliev suggested framing security considerations as neutral risk assessments rather than "proponent" vs. "opponent" views.
Opposition: Ousama expressed strong opposition, arguing that moving from hybrid to ML-KEM-only constitutes a security degradation and that the work should have originated in CFRG.
Privacy: John Gray raised concerns regarding the privacy implications of static key use and NIST 800-227 compliance.

### PQC Continuity

Yaron Sheffer presented a proposal for rollback resistance during the PQC transition.

The proposal uses a Trust-on-First-Use (TOFU) mechanism where a server signs a commitment to support PQC for a specific duration. Clients cache this and fail handshakes if a server later presents a non-PQC chain.
Eric Rescorla questioned if there is substantial implementation interest in a TLS-layer solution versus HTTPS-layer (HSTS-style) or PKI-layer solutions. The discussion was moved to the mailing list.

## Decisions and Action Items

[draft-ietf-tls-mldsa]: Tim Hollebeek to work with Eric Rescorla and Victor Vasiliev to refine the normative text regarding the TLS 1.2 prohibition (clarifying its impact on certificate chains) before initiating WGLC.
[draft-ietf-tls-pake]: Laura Handly to add a security consideration regarding discrete log vulnerabilities in Spake2+ as raised by Scott Fluhrer.
[draft-ietf-tls-mlkem]: Deirdre Connolly to review GitHub issues regarding static key ownership and privacy aspects raised by John Gray.

## Next Steps

Chairs will provide a formal summary of the consensus status for [draft-ietf-tls-mlkem] on the mailing list, addressing the split between those supporting the draft, those opposing it, and those requesting specific document improvements.
Authors of [draft-ietf-tls-pake] will continue the ProVerif formal analysis and share results with the working group.
The second TLS session (Friday) will include further discussion on the FAT process and other active drafts including [draft-ietf-tls-tlsflags] and [draft-ietf-tls-wkech].

Session Date/Time: 20 Mar 2026 06:00

TLS

Summary

The TLS Working Group met at IETF 125 to discuss the status of core documents, cryptographic updates, and new extensions. Key focus areas included the progression of draft-ietf-tls-mlkem, the security analysis of draft-ietf-tls-extended-key-update, and measurement data regarding Encrypted Client Hello (ECH) deployment. The group also debated the necessity of supporting large handshake messages for post-quantum algorithms and considered proposals for workload identity hints and signed ECH configurations.

Key Discussion Points

Working Group Status and 8446bis

Sean Turner (Chair) announced a proposal to prohibit ephemeral key reuse in the main body of RFC 8446bis. A two-week consensus call will be initiated to move this requirement from the appendix to the normative text.
draft-ietf-tls-mlkem: The chairs reported that consensus has not yet been reached to progress the document. Key issues to resolve include:
- Addressing key reuse (aligned with 8446bis changes).
- Adding text regarding a preference for hybrid key exchange.
- Including motivation for pure ML-KEM (referencing a liaison from IEEE).
- Muhammad Usama Sardar and Tanya expressed concerns regarding the loss of security properties when moving from hybrid to pure ML-KEM. Tom van der Meent and Victor Duchovni noted that while non-hybrids are controversial, the protocol interaction is well-understood.

Formal Analysis Triage (FAT) Team Update

Tom van der Meent presented the FAT Update focusing on draft-ietf-tls-extended-key-update.
Technical Challenges: Extended Key Update (EKU) attempts to provide Post-Compromise Security (PCS), which is significantly harder to model than standard Forward Secrecy because it requires "kicking out" an active adversary from a compromised state.
Subtleties identified:
- Transcript Binding: Previous versions unlinked the new keys from the handshake transcript; authors have since fixed this by incorporating the previous transcript hash.
- Session Tickets: If session tickets are not discarded after an EKU, an attacker who compromised the initial state might still be able to resume the session later.
The FAT team concluded that specialized analysis is needed and that authors should clarify the threat model (e.g., handling of session tickets).

Extended Key Update (EKU)

Yaroslav Rosomakho presented updates for draft-ietf-tls-extended-key-update.
Changes: Reduced the number of message flights, updated the key schedule to include a rolling transcript, and updated exporter considerations.
Discussion: Eric Rescorla (Ecker) and Yaroslav Rosomakho discussed the relevance of Trusted Execution Environments (TEEs). Ecker argued that TEE terminology is often a distraction and that the core issue is simply whether keys are in "secure storage" or not. John Mattsson suggested that built-in re-authentication would be beneficial to avoid application-layer changes.

Large Handshake Data

Valery Smyslov discussed proposals for handling large handshake messages (e.g., for large post-quantum key shares) in the context of draft-ietf-tls-super-jumbo-record-limit.
Proposals included extending ClientHello/ServerHello, using EKU for a secondary exchange, or a new AuxHandshakeData message.
Eric Rescorla argued against solving this problem currently, stating it is an "intellectual problem" with no immediate practical need, as most PQ algorithms fit within existing limits. No consensus was reached to move forward.

Formal Analysis Best Practices

Muhammad Usama Sardar proposed a template and process for formal analysis (PQC Continuity).
Suggestions included better transparency (dashboards for FAT reviews) and standardized author templates for threat models and security goals.
Eric Rescorla supported the transparency/dashboard concept but resisted creating a formal "Verifier" role or special process for other working groups to consult TLS, preferring to maintain existing informal structures.

ECH Measurements and Signed Configs

Yaroslav Rosomakho presented measurement data on ECH and HTTPS Resource Records (RR).
- Findings: Waiting for HTTPS RR has minimal latency impact in most cases, but some domains (notably .gov) are "defective" and do not respond, necessitating a timeout cap.
- ECH GREASE showed no significant connectivity breakage across 10,000 domains and various mobile networks.
Dennis Jackson presented Signed ECH Configs.
- The goal is to allow "randomized" outer SNIs without needing a registered domain or valid TLS certificate for the cover name.
- Authentication is moved to a signing key hash in DNS. This reduces "shared fate" and fingerprinting by middleboxes.
- Eric Rescorla expressed interest, particularly regarding robustness against fragility, and supported moving toward raw public keys rather than certificates for authentication.

Workload Identifier Origin Hint

Yaroslav Rosomakho presented a proposal for a ClientHello extension to hint at workload identities for mTLS.
The hint helps servers choose the correct CA list for a CertificateRequest, avoiding the need for separate endpoints for different client types.
Eric Rescorla and Dennis Jackson raised privacy concerns regarding leaking trust domains in the cleartext portion of the ClientHello and suggested using a simple flag or ECH to protect this information.

Decisions and Action Items

RFC 8446bis: Chairs will start a two-week consensus call to normatively prohibit ephemeral key reuse.
draft-ietf-tls-mlkem: Authors to update the draft with hybrid preference text and address key reuse; a targeted working group last call will follow.
draft-ietf-tls-extended-key-update: Authors will continue to refine the draft, specifically addressing session ticket disposal and editorial feedback regarding TEEs.

Next Steps

Authors of Signed ECH Configs will trim the draft to focus on raw public keys based on feedback.
The Working Group will continue to monitor ECH deployment data to inform default-enablement recommendations in libraries.
The FAT Team will continue to engage with EKU authors as the protocol matures.

Automatic IETF Minutes

TLS