Markdown Version | Transcript | Session Recording | Session Materials

SAAG

Summary

The Security Area Advisory Group (SAAG) met at IETF 126 to discuss security area updates, review security directorate statistics, and host two technical presentations. The first technical presentation, by David Benjamin, focused on transition strategies for post-quantum web authentication. The second presentation, by Mike Ounsworth, addressed privacy considerations and trust model gaps in remote attestation (RATS). The session concluded with an open mic discussion regarding the status of RFC 4086.

Key Discussion Points

1. Area Updates and Dispatching

• DISPATCH Working Group Restructuring: The sec-dispatch working group is being closed. Its responsibilities are merging with dispatch (under the ART area) along with non-transport WIT area dispatching into a single combined dispatch working group. A new chair is being sought for the security portion of this list.
• Working Group Status:
  • Rechartered: OAuth and Radext.
  • Rechartering in progress: SPICE.
  • Winding down: PQUIP is finalizing its last documents before closing.
• Security-Adjacent Work in Other Areas:
  • OPSAWG: Review is requested for draft-parsons-opsawg-security-operations (Security Operations Guidance).
  • WIMSE: Preparing several drafts for IESG-wide review and seeking broad security feedback.
  • vCon: Incorporating verifiable agent conversation records to progress auditing work.
  • NTP: Experiencing ongoing work on NTS-enabled NTP pool deployment via draft-ietf-ntp-nts-keyexchange-pool.

2. Security Directorate (SecDir) Statistics

• Presented by Deb Cooley and Roman Danyliw.
• Slides: SecDir Review Statistics IETF-126
• The Security Area currently manages 30 working groups, overseeing 314 active documents spanning over 11,000 pages.
• Reviewer statistics, on-time performance, and a SecDir "Hall of Fame" recognizing top contributors by document and page count were presented.

3. Post-Quantum Authentication - Beating the S-Curve

• Presented by David Benjamin.
• Slides: Post-Quantum Authentication - Beating the S-Curve
• The Transition Problem: While key agreement transition (ML-KEM) is progressing, post-quantum authentication (signatures) presents a different challenge due to the "S-curve" of server and client upgrades. If updated clients continue to accept classical certificates for compatibility reasons, an active attacker with a Cryptanalytically Relevant Quantum Computer (CRQC) can simply forge a classical certificate to compromise the connection.
• Transition Mechanisms:
  • PQ-HSTS: Useful for preventing downgrade attacks but suffers from scalability limits, privacy concerns, and lack of first-visit protection.
  • CA-First Migration: Migration of CA root keys is faster than individual server keys. However, legacy clients cannot parse PQ CA signatures.
  • Multi-Cert / Hybrid Negotiation: Ideally, servers negotiate PQ or classical certificates on demand. However, current legacy server deployments often support only a single certificate slot.
• "Turducken" / "Frankencert" Certificates: To bridge the gap, the presenter proposed wrapping or smuggling PQ-secure data (such as a PQ signature or Signed Certificate Timestamp) inside an extension of a standard classical certificate. Legacy clients parse only the outer classical structure, while upgraded clients extract the inner PQ proof.
• Discussion:
  • Phillip Hallam-Baker noted historical parallels with the SHA-1 to SHA-256 transition.
  • Alicja Kwasniewska raised concerns about the complexity and long-term baggage of "Turducken" certs, suggesting a downgrade flag instead. David Benjamin replied that a flag signed only classically can be stripped by a quantum adversary.
  • Dennis Jackson remarked that while PQ-HSTS and "Turducken" certificates address different timescales, both require careful integration with CT log ecosystems.
  • Daniel Kahn Gillmor queried who enforces the exclusion of unauthorized duplicate classical certs once PQ is established. David Benjamin emphasized the utility of CT monitoring and potential CA authorization records.
  • Russ Housley noted that similar concepts were explored during the design of X.509 v4 but warned that complex nesting can cause parsers to fail.
  • Dmitry Shikhmanter cautioned against assuming a gradual warning period for CRQC capabilities, citing closed academic dynamics and quantum error-correction developments.
  • Mike Ounsworth suggested aligning this direction with existing LAMPS drafts, such as draft-ietf-lamps-certdiscovery and the "Chameleon" certificate concepts in draft-bonnell-lamps-chameleon-certs.

4. Privacy and Attestation

• Presented by Mike Ounsworth.
• Slides: Privacy and Attestation
• The Problem: The Remote Attestation Procedures (RATS) architecture (RFC 9334) lacks a standardized, built-in privacy layer. When devices attest to a remote verifier, they risk exposing sensitive, personally/system-identifiable information (PII/SII) to a malicious, passive, or coercive verifier.
• Proposed Framework:
  • Classifying verifiers into distinct roles (e.g., network admin, manufacturer, security officer) and limiting the detail of released evidence based on authorization.
  • Standardizing object-level encryption for evidence to prevent middleboxes from logging sensitive attestation payloads.
• Discussion:
  • Usama Yasmin pointed out that privacy was intentionally excluded from the original RATS scope due to the failure and complexity of past industry attempts like Intel EPID/EPIC.
  • Hank Birkholz highlighted that although the RATS architecture recognizes the privacy problem conceptually, specifying the solution introduces difficult policy challenges that have historically been out of scope for the working group.
  • Stephen Farrell suggested categorizing the technical work into two areas: zero-knowledge proofs to hide information from the verifier itself, and object encryption to conceal information from intermediary parties.

5. Any Other Business (AOB): Status of RFC 4086

• Yoav Nir suggested that RFC 4086 ("Randomness Requirements for Security") is obsolete and should be moved to Historic status. Modern systems should rely on native operating system random number generators (RNGs) rather than letting applications build their own software entropy pools.
• Deb Cooley agreed that retiring RFC 4086 to Historic is a straightforward task, while writing a comprehensive replacement would be complex. The CFRG's RFC 8937 was noted as a modern, narrower reference for RNG safety.

Decisions and Action Items

• SEC DISPATCH Closure: The sec-dispatch working group is officially closing. Future security dispatching will occur under the unified dispatch mailing list and sessions.
• RFC 4086 Review: The Area Directors will look into initiating the process to designate RFC 4086 as Historic.

Related Documents

draft-bonnell-lamps-chameleon-certs, draft-ietf-lamps-certdiscovery, draft-ietf-ntp-nts-keyexchange-pool, draft-parsons-opsawg-security-operations