IETF 125 TLS WG Monday session

Notetakers: Yan Bo Ti, Felix Linker

Intro statements

• Intellectual Property: IRTF follows IETF IPR disclosure rules
• Privacy and Code of Conduct: RFCs 7154, 7776, 9775
• Goals: Long-term research issues
• Agenda: Administrativia, drafs, Multiverse
• Document status: 2 RFCs published

WG Status (10min)

Chairs

• Covered published RFCs, and status of various drafts
• Implementations status
• Hannes has an implementation.

Working Group Drafts (30min)

Use of ML-DSA in TLS 1.3 (5min)

Tim Hollebeek
draft-ietf-tls-mldsa

Points by Tim:

• General update on this draft whose purpose is to have an RFC for
  people to refer to.
• Just registers 3 ML-DSA sizes
• Specifies use in TLS 1.3
• Prohibits use in TLS 1.2
• Hybrid out of scope
• Stable now, and speed is key to not bottleneck the process
• Question: (Richard Barnes) Why not just reference to FIPS, and
  no need for this draft.
  Answer: Small added value is to specify that this is not for TLS
  1.2, and specifying pre-hash use, context string use, etc. FIPS also
  do not specify for TLS.

Decision: Create list of raised issues before proceeding to WGLC.

A Password Authenticated Key Exchange Extension for TLS 1.3 (15min)

Laura Bauman
draft-ietf-tls-pake

Points by Laura:

• No clear arguments for changing client/server identity negotiation
• To add text on use cases/motivation

• Next step: Add ProVerif model to GitHub to prove that explicit key
  confirmation messages can be replaced by TLS finished messages, can
  move to last-call

• (Muhammad Usama Sardar) Thanks for adding a slide on formal
  analysis. This avoids repititive effort. The property as stated does
  not seem to be verifiable in ProVerif.

Raised issues:

• Security considerations may need extension, e.g., PQ threats.
• Draft may need substantial security analysis

Decision:

• Chairs will follow-up with authors about next steps.
• Likely, there must be results of formal analysis before WGLC.

ML-KEM Post-Quantum Key Agreement for TLS 1.3 (10min)

Deirdre Connolly
draft-ietf-tls-mlkem

Points by Deirdre:

• Main updates are to remove structures with 8446, move "MUST NOT
  reuse CT randomness" to become nomative, add references, add/modify
  some language.

Raised issues:

• (Deirdre) Can we remove motivation section?
  (Viktor Dukhovni) Perhaps change motivation to highlighting risks
  while staying neutral
• (Muhammad Usama Sardar)
  Slides were not uploaded in time, and it was very quick pass over
  slides.
  1. Motivation is necessary. It should NOT be removed. If there is
     no motivation, it is unnecessary work.
  2. This should first go to CFRG/FATT and then bring their
     attestation here. TLS should not be the first one to take it up.
  3. From a formal perspective, replacing hybrid (ECDH || MLKEM)
     with ML-KEM is a degradation of compositional property.
     (Deirdre) Disagree and take offline

Decision:

• The chairs will provide further explanation on outcomes of WGLC to
  the WG next week

PQ Continuity: Downgrade protection

Yaron Sheffer
draft-sheffer-tls-pqc-continuity

Points by Yaron:

• HSTS at TLS layer; no PKI changes needed
• Client certificate support still an open issue
• Many issues with CDNs and middleboxes

Raised issues:

• Are there major implementors?

Decision:

• Further discussions on list

IETF 125 TLS WG Friday session

Notetakers: Felix Linker

Working Group Status and 8446bis

Prohibit Ephemeral Key Reuse in -rfc8446bis

• Sean Turner (Chair) announced a proposal to prohibit ephemeral key
  reuse in the main body of -rfc8446bis. A two-week consensus
  call will be initiated to move this requirement from the appendix to
  the normative text.

WGLC ML-KEM Status

• 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 Lange expressed concerns regarding the
loss of security properties when moving from hybrid to pure ML-KEM.

Tom Wiggers and Victor Duchovni noted that while non-hybrids are
controversial, the protocol interaction is well-understood.

Chairs will issue targeted WGLC after these issues are addressed.

Extended Key Update

FATT Analysis Summary

Formal Analysis Triage (FAT) Team Update

Thom Wiggers
FAT Update for draft-ietf-tls-extended-key-update

Points by Thom:

• 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
draft-ietf-tls-extended-key-update

Points by Yaroslav:

• Reduced the number of message flights, updated the key schedule to
  include a rolling transcript, and updated exporter considerations.

Raised Issue:

• Eric Rescorla (ekr) and Yaroslav Rosomakho discussed the relevance
  of Trusted Execution Environments (TEEs). ekr 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.

Decision:

• Authors will continue to refine the draft, specifically addressing
  session ticket disposal and editorial feedback regarding TEEs.

Beyond the 64K Limit in TLS 1.3 Handshake

Valery Smyslov
draft-ietf-tls-super-jumbo-record-limit

Points by Valery:

• Proposals includes extending ClientHello/ServerHello, using EKU
  for a secondary exchange, or a new AuxHandshakeData message.

Points made by ekr:

• 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.

Extensions of TLS FATT Process

Muhammad Usama Sardar

Points by Usama:

• Suggests including better transparency (dashboards for FAT reviews)
  and standardized author templates for threat models and security
  goals.

Points made by ekr:

• 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.

Decisions:

• Chairs to update Usama's PR with additional information.

ECH Measurements

Vinicius Fortuna

Observations from Vinicius:

• 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.

Decisions:

• ekr agreed to help Vinicius track down contacts at .gov.

Signed ECH Configs

Dennis Jackson
Signed ECH Configs.

Points by Dennis:

• 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.

Points by ekr:

• Expressed interest, particularly regarding robustness against
  fragility, and supported moving toward raw public keys rather than
  certificates for authentication.

Decisions:

• Authors will trim the draft to focus on raw public keys based on
  feedback.
• WG will continue to monitor ECH deployment data to inform
  default-enablement recommendations in libraries.

WIMSE Cert Hint

Yaroslav Rosomakho
Workload Identifier Origin Hint for TLS ClientHello

Points by Yaroslav:

• The hint helps servers choose the correct CA list for a
  CertificateRequest, avoiding the need for separate endpoints for
  different client types.

Points by ekr and Dennis Jackson:

• There are 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.