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

TLS

Summary

The TLS Working Group met at IETF 126 to discuss the status of active working group drafts, address recent mailing list behavior, review updates to DTLS 1.3, and evaluate several newly proposed drafts.

Key outcomes included a clear mandate for the chairs to exercise stronger moderation controls over the mailing list, a consensus decision to require replay protection in DTLS 1.3, and plans to take several active or proposed drafts (such as signed Encrypted Client Hello (ECH) updates and workload identifier scope hints) to the mailing list for further discussion or adoption calls.

Key Discussion Points

1. TLS WG Update

Sean Turner presented the WG status update using the slide deck TLS WG Update.

• Document Status:
  • draft-ietf-tls-extended-key-update is functionally complete but awaiting formal analysis from the Formal Analysis Triage Team (FATT). Eric Rescorla suggested that if the working group also proceeds with supplemental certificates, a joint analysis of both should be performed due to their interdependencies.
  • draft-ietf-tls-pake has received initial analysis input, and chairs will request FATT to assign a point person.
  • draft-ietf-tls-super-jumbo-record-limit is awaiting a second independent implementation.
  • draft-ietf-tls-key-share-prediction, draft-ietf-tls-trust-anchor-ids, and draft-ietf-tls-tlsflags remain in a state of waiting for implementation experience.
  • draft-ietf-tls-wkech is currently waiting for a second implementation.
  • The hybrid post-quantum key agreement (draft-ietf-tls-mlkem) has been progressed.
• Mailing List Moderation: The chairs addressed recent highly toxic list behavior and requested backing for stronger, more proactive moderation actions, including squelching off-topic process-oriented threads. The room strongly supported tougher moderation.
  • Poll 1: Do you want the list to get more functional? — yes: 81, no: 0, no_opinion: 3 (total: 136)
  • Poll 2: Should the chairs be more draconian in their dolling out of moderation actions? — yes: 0, no: 1, no_opinion: 0 (total: 138)
  • Poll 3: Should the chairs be more draconian in their dolling out of moderation actions? — yes: 65, no: 2, no_opinion: 7 (total: 143)
• FATT Process Improvements: The chairs polled the group on whether the FATT procedural debates have been a distraction and how the workflow should behave.
  • Poll 4: Do you think FATT procedural discussions are a distraction? — yes: 35, no: 0, no_opinion: 8 (total: 150)
  • Poll 5: Do you think chairs should be the ones that determine whether a draft goes for the initial sniff test?ss — yes: 42, no: 1, no_opinion: 4 (total: 150)
  • Poll 6: Do you think authors and those performing the formal analysis should collaborate? — yes: 49, no: 3, no_opinion: 8 (total: 150)

2. DTLS 1.3

Eric Rescorla presented updates to draft-ietf-tls-rfc9147bis based on the DTLS 1.3 slide deck.

• Replay Protection (PR 317): Replay protection was previously optional in DTLS. Eric Rescorla proposed making replay protection mandatory. This simplifies analysis, and previous performance and protocol-specific concerns (e.g., from SCTP) are no longer blocking issues. Martin Thomson and David Benjamin supported making replay protection mandatory. No objections were raised in the room or chat.
• Epoch Closure (PR 326): David Benjamin highlighted remaining ambiguities about when to close epochs safely. Eric Rescorla requested further offline review from David Benjamin and Martin Thomson to finalize this logic.

3. Authenticated ECH Config Distribution and Rotation

Alessandro Ghedini presented Authenticated ECH Config Distribution and Rotation, detailing draft-sullivan-tls-signed-ech-updates.

• Overview: The draft proposes an RPK-based (Raw Public Key) signing mechanism for Encrypted Client Hello (ECH) configurations. This decouples ECH config rotation from web TLS certificates, allowing offline configuration signing.
• Discussion: Eric Rescorla raised concern about replay attacks on signed "disablement" ECH configs, noting that an attacker could replay a disablement config to turn off ECH for the client. Dennis Jackson noted this is an active design trade-off: preventing the replay would require keeping the signing key online in the TLS server, which defeats the offline-signing benefit.
• WG Interest and Adoption Polls:
  • Poll 7: Who has read the draft-sullivan-tls-signed-ech-updates? — yes: 11, no: 28, no_opinion: 4 (total: 152)
  • Poll 8: Should the TLS WG adopt draft-sullivan-tls-signed-ech-updates? — yes: 12, no: 9, no_opinion: 19 (total: 152)
  • Outcome: The adoption decision will be taken to the mailing list due to the split room.

4. Workload Identifier Scope Hint

Yaroslav Rosomakho presented Workload Identifier Scope Hint covering draft-rosomakho-tls-wimse-cert-hint.

• Overview: Under mutually authenticated TLS (mTLS) for workloads (e.g., SPIFFE in WIMSE), clients can use this new TLS Client Hello extension to hint at their workload identity scope, letting servers know whether and how to construct a certificate request.
• Discussion: Victor Dukhovni and Shumon Huque noted significant overlap with ongoing DANE-specific client-solicitation extensions under development in the DANCE working group. Eric Rescorla voiced concern over having multiple disjoint TLS extensions that signal client authentication readiness, suggesting that the working group should standardize a generalized, high-level client-cert solicitation mechanism instead.
• WG Interest Poll:
  • Poll 9: Who has read draft-rosomakho-tls-wimse-cert-hint? — yes: 8, no: 24, no_opinion: 0 (total: 154)

5. Supplemental Authentication in TLS 1.3

Yaroslav Rosomakho presented Supplemental Authentication in TLS 1.3 based on draft-rosomakho-tls-supplemental-auth.

• Overview: This draft introduces a mechanism to carry multiple client/server certificates (e.g., separate user and device certificates in enterprise VPNs or distinct host-identity and workload-identity certificates on servers) inside a single TLS connection.
• Discussion:
  • Alicja Kario strongly objected to the server-side changes, arguing that servers requiring multiple identities should use a single multi-identity certificate or enforce post-handshake application-layer validation.
  • Jonathan Hoyland, Andre Popov, and Dennis Jackson questioned the introduction of complex new handshake states, pointing out that existing RFCs like Exported Authenticators (RFC 9261) or post-handshake authentication (RFC 9266) could solve these use cases without risking new protocol vulnerabilities.

6. PQC Continuity

Yaron Sheffer presented PQC Continuity on draft-sheffer-tls-pqc-continuity.

• Overview: This draft introduces a trust-on-first-use (TOFU) server commitment mechanism. A server commits to presenting post-quantum certificates for a given duration, which the client caches to prevent future downgrade/rollback attacks to classical algorithms.
• Discussion: David Benjamin and Dennis Jackson argued that caching and managing security context is inherently an application-layer concern (similar to HSTS). They stated that an HTTP-level HSTS-based mechanism would be more appropriate and functional for web environments than managing this state at the TLS layer. Yaron Sheffer responded that an HTTP-level solution introduces its own layering violations.
• WG Interest Poll:
  • Poll 10: Who has read draft-sheffer-tls-pqc-continuity? — yes: 14, no: 12, no_opinion: 0 (total: 153)

Decisions and Action Items

Decisions

1. DTLS 1.3 Replay Protection: Replay protection will be made mandatory in draft-ietf-tls-rfc9147bis (PR 317 will be merged).
2. Mailing List Moderation: The chairs will implement stricter moderation policies, including thread squelching and potential moderation queues, to protect the mailing list from toxic behavior and unproductive process debates.

Action Items

1. Chairs: Issue an adoption call on the mailing list for draft-sullivan-tls-signed-ech-updates.
2. Chairs: Initiate the FATT point person assignment for draft-ietf-tls-pake.
3. Yaroslav Rosomakho & Shumon Huque: Coordinate on overlapping extension semantics between WIMSE client certificate hints (draft-rosomakho-tls-wimse-cert-hint) and DANCE's client certificate solicitation work.
4. David Benjamin & Martin Thomson: Provide detailed feedback and review on epoch closure handling (PR 326) in draft-ietf-tls-rfc9147bis.

Next Steps

• The working group will continue to monitor implementations of draft-ietf-tls-super-jumbo-record-limit and draft-ietf-tls-wkech to meet the two-independent-implementation requirement.
• FATT reviews for draft-ietf-tls-extended-key-update will proceed before launching a formal Working Group Last Call.

Session Date/Time: 24 Jul 2026 14:00

TLS

Summary

The TLS Working Group met at IETF 126 to discuss several active initiatives, including password-authenticated key exchange (PAKE) mechanisms, hybrid post-quantum and traditional (PQ + T) signature schemes, XOF-based key schedules, and empirical measurements of Encrypted Client Hello (ECH) deployments. The group held key discussions on whether to pursue dual certificates or composite signatures for PQ+T hybrid authentication, resulting in a clear preference to focus work on composite signatures.

Key Discussion Points

1. PAKE Extension for TLS 1.3

Christopher Wood presented an update on draft-ietf-tls-pake (A Password Authenticated Key Exchange Extension for TLS 1.3).

• Presentation: A Password Authenticated Key Exchange Extension for TLS 1.3
• Summary: Christopher Wood explained how the extension negotiates a PAKE within the TLS 1.3 handshake, combining it with the TLS shared secret. He highlighted the Finished message's role in key confirmation, guidance on external PAKE negotiation via the PSK importer draft, and symbolic security analysis performed using ProVerif.
• Discussion:
  • Eric Rescorla sought clarification on whether the Finished message provides key confirmation. Christopher Wood and Scott Fluhrer confirmed that it does.
  • Scott Fluhrer noted that Opaque PAKE integration operates differently from the framework in the draft and argued that it should be kept out of scope or treated in a separate document.
  • Victor Dukhovni raised questions regarding resumption tickets and potential security or negotiation implications when resuming after a PAKE negotiation.
  • Mohit Sahni asked about feature combinations (e.g., PAKE combined with certificate-based authentication or ECH) and noted that computational analysis would be needed to verify dropping the key confirmation step.
  • Sean Turner (Chair) noted that he is preparing to coordinate with the formal analysis team (FAT) to begin evaluating the draft.

2. Framing PQ + T Signatures for TLS

Sean Turner introduced the discussion on post-quantum and traditional (PQ + T) hybrid signature schemes.

• Presentation: Framing PQ + T Signatures for TLS
• Summary: Sean Turner framed the discussion as an architectural decision regarding the approach to hybrid signatures, emphasizing that the focus was not on specific algorithms but rather on the mechanism of integration.

A. Dual Certificates in TLS 1.3

Rifaat Shekh-Yusef and Hannes Tschofenig presented the dual-certificates approach.

• Presentation: Dual Certs in TLS 1.3
• Summary: The presenters outlined how dual certificates utilize two distinct PKI hierarchies (traditional and PQC) and supply two certificate chains within the TLS handshake. This approach attempts to minimize PKI complexity by avoiding hybrid certificates but binds the signatures at the TLS level during the certificate verification phase.
• Discussion:
  • David Benjamin noted that this approach does not resolve the transition/migration issues discussed in the Security Area Advisory Group (SAAG) because it still requires updating the TLS server.
  • Jonathan Hoyland and Mohit Sahni questioned how the two keys are cryptographically bound, asking why the output of the first signature is not fed into the input of the second. Tiru Reddy explained that they rely on the overall handshake transcript containing both certificate chains to achieve weak non-separability, citing analysis from the PQ working group.
  • Andrei Popov and Bob Beck questioned how backwards compatibility would work, asking how a server upgraded to dual certificates would handle non-upgraded clients. Tiru Reddy responded that the server would fall back to traditional certificates based on client capability negotiation.
  • Eric Rescorla pointed out that the proposed design introduces unusual semantics to TLS signature scheme negotiation, where certain advertised signature schemes would be restricted to the CertificateVerify message and could not be used to sign certificates.
  • Victor Dukhovni remarked that the dual-certificate proposal essentially represents a workaround for "hybrids with CAs that don't do hybrids."

B. Composite Signatures (Use of Composite ML-DSA in TLS 1.3)

Tiru Reddy presented the composite signature approach.

• Presentation: Use of Composite ML-DSA in TLS 1.3
• Summary: Tiru Reddy described composite signatures as an approach where traditional and PQC public keys and signatures are handled as a single, atomic, opaque object at the TLS layer. This method is being standardized in the LAMPS working group and requires virtually no changes to the TLS protocol itself, as it relies on existing TLS 1.3 extensions and treats the composite keys as standard signature algorithms.
• Discussion:
  • Nicola Tuveri shared positive deployment feedback, reporting that his team successfully deployed composite ML-DSA in both web and mutual-TLS IoT scenarios, noting that treating the algorithm as opaque significantly simplified the implementation.
  • Eric Rescorla, Rich Salz, and Dennis Jackson questioned the overall utility of hybrid signatures, suggesting that simple algorithm transitions may be preferable. However, they noted that if the working group chooses to support a hybrid signature mechanism for "hedging," the composite approach has a significantly lower protocol and API complexity cost.
  • Andrei Popov expressed strong support for the composite approach because it avoids changing TLS APIs. John Gray and Christopher Wood also supported the composite approach for hedging, especially in non-web or raw-public-key environments.

3. XOF-Based Key Schedules for TLS 1.3

Nick Sullivan presented a proposal to introduce Extendable-Output Function (XOF) based key schedules into TLS 1.3.

• Presentation: XOF-based key schedules for TLS 1.3
• Summary: The proposal replaces SHA-2/HKDF components in the TLS 1.3 key schedule with Keccak-based primitives (such as KMAC and SHAKE). Using doubly-extended cryptographic keyed deck functions, the key schedule can be optimized from 156 permutation calls down to 39, offering significant performance improvements for devices utilizing post-quantum algorithms (which already rely heavily on Keccak).
• Discussion:
  • Mohit Sahni asked whether the analysis required for this work was cryptographic or symbolic. Nick Sullivan indicated that any analysis is welcome, though the current model aligns closely with standard NIST TLS 1.3 proofs.
  • Quynh Dang (Nist) expressed support for the concept, stating that NIST would evaluate the security of the design once finalized and look for ways to approve it if it meets security requirements.
  • John Preuß Mattsson strongly supported the work, noting that a SHA-3-based family option is highly desirable given the PQC migration.
  • Eric Rescorla and Nick Sullivan discussed the negotiation mechanics. Eric Rescorla argued that instead of negotiating the key schedule profile via a new TLS extension, it would be architecturally cleaner to define new cipher suites that natively map to SHA-3/Keccak transcript hashes and key schedules.

4. Encrypted Client Hello (ECH) Active Measurements

Jonas presented research on active measurements of Encrypted Client Hello (ECH) deployments.

• Presentation: Encrypted Client Hello (ECH) - An active measurement perspective
• Summary: Jonas outlined empirical research tracking ECH deployment, observing over 4 million ECH-supporting domains. While Cloudflare remains the largest operator, the researchers discovered a large, functional ECH deployment by Meta that does not publish ECH configurations in public DNS, instead utilizing a retry-based mechanism. The study also characterized configuration rotation, grace periods, and a minor latency increase associated with ECH handshakes.
• Discussion:
  • Kyle Nekritz confirmed Meta's active and widespread deployment of ECH within their primary application, noting that it is highly performant.

Decisions and Action Items

Session Polls

The chairs conducted several polls to determine the path forward on PQ + T hybrid signatures:

1. Do we have enough information to take a decision on the way forward for PQ + T Signatures for TLS?

   • Result: yes: 67, no: 10, no_opinion: 1 (total: 146)

2. Should the WG work on PQ + T Signatures for TLS?

   • Result: yes: 53, no: 20, no_opinion: 12 (total: 148)

3. Should the WG only work on one: -pqt-dual-certs or -composite-ml-dsa?

   • Result: yes: 55, no: 11, no_opinion: 14 (total: 149)

4. Should the WG work only on: -pqt-dual-certs?

   • Result: yes: 8, no: 51, no_opinion: 12 (total: 148)

5. Should the WG work only on: -composite-ml-dsa?

   • Result: yes: 53, no: 8, no_opinion: 17 (total: 149)

6. Can we allocate code points and move?

   • Result: yes: 11, no: 7, no_opinion: 3 (total: 151)

7. Can we allocate code points and not adopt the draft?

   • Result: yes: 31, no: 23, no_opinion: 8 (total: 151)

Key Decisions

• PQ + T Signatures Strategy: The working group demonstrated a clear preference to work on only one hybrid signature design, specifically selecting the composite signature approach (-composite-ml-dsa) over the dual-certificates approach (-pqt-dual-certs).

Next Steps

• Hybrid Signatures: The chairs will take the preference for adopting -composite-ml-dsa and rejecting -pqt-dual-certs to the mailing list to confirm working group consensus.
• PAKE Draft: The chairs will coordinate with the formal analysis team (FAT) to initiate the review of draft-ietf-tls-pake.

Related Documents

draft-ietf-tls-extended-key-update, draft-ietf-tls-key-share-prediction, draft-ietf-tls-mlkem, draft-ietf-tls-pake, draft-ietf-tls-rfc9147bis, draft-ietf-tls-super-jumbo-record-limit, draft-ietf-tls-tlsflags, draft-ietf-tls-trust-anchor-ids, draft-ietf-tls-wkech, draft-rosomakho-tls-supplemental-auth, draft-rosomakho-tls-wimse-cert-hint, draft-sheffer-tls-pqc-continuity, draft-sullivan-tls-signed-ech-updates