Markdown Version | Transcript | Session Recording | Session Materials
Session Date/Time: 16 Mar 2026 08:30
PLANTS
IETF 125 Session Minutes
Summary
The PLANTS (Post-Quantum Low-Latency ArchiTecture for Network Security) working group held its first official meeting at IETF 125. The session focused on the recently adopted draft-ietf-plants-merkle-tree-certs, establishing working group procedures for GitHub, discussing the forthcoming architecture document, and reviewing early experimental results from a Chrome-Cloudflare deployment. Key technical discussions included log generations for incident recovery, verifiable server monitoring, and the use of Merkle Tree Certificates (MTC) in private PKI contexts.
Key Discussion Points
WG Introduction and GitHub Policy
- Presenters: Tom Ritter and Russ Housley (Chairs)
- Slides: PLANTS WG Chair Introduction, PLANTS GitHub policy
- The group discussed how to manage technical work. Tom Ritter proposed the "Issue Discussion Mode" for GitHub usage, where substantive technical matters can be discussed in GitHub issues, provided major decision points and summaries are brought back to the mailing list.
- Mike (participation via queue) supported the use of GitHub but emphasized that the mailing list remains the primary point of entry for many participants and requires proactive summaries from authors.
Document Update: draft-ietf-plants-merkle-tree-certs
- Presenter: David Benjamin
- Slides: Lettuce Get To Work
- Terminology: The draft has been updated to use "standalone certificate" (formerly full certificate) and "landmark certificate" (formerly signatureless).
- Architecture Document: Per the charter, the current "jumbo" draft needs to be split. The new architecture document will clarify where MTC fits into the broader log transparency ecosystem (e.g., relationship with Tlog) and identify applicable application contexts.
- Log Generations: David proposed a mechanism to allow CAs to recover from state failures (e.g., bit flips or database resets) by using a sequence of numbered logs. This prevents a CA from being permanently "locked out" by cosigners if it commits to an inconsistent state.
- Trust Anchors: Discussion on how to represent an MTC CA for non-transparency-enforcing relying parties, potentially using a new Subject Public Key Info (SPKI) type or critical extensions in self-signed certificates.
Server Monitoring
- Presenter: Brendan McMillian
- Slides: Server Monitoring
- Brendan highlighted a security gap: current monitoring often relies on unvetted third-party services. He proposed aligning monitoring security with browser security by adding "accumulated" log entries to CA logs. These entries would contain verifiable index root hashes cosigned by the same quorum the browser trusts.
- A PR is open to add a counter to log entries to allow for verifiable, efficient searching of these index updates.
- Discussion: Filippo Valsorda and David Benjamin discussed the granularity of these counters and whether they should be per-index-operator or batched.
MTC Experiment: Early Results
- Presenter: Luke Valenta
- Slides: MTC experiment early results
- Luke presented data from a joint Chrome and Cloudflare experiment using landmark MTCs over 1,000 domains.
- Performance: Even with classical signatures, MTC handshakes were ~9% faster at the median (105ms vs 116ms) due to reduced bytes on the wire compared to traditional X.509 + CT chains.
- Reliability: 99% of clients successfully updated landmarks within a few hours. No significant middlebox interference was observed, largely because the server certificate is encrypted in TLS 1.3.
Pruning MTC for Diverse Environments
- Presenter: Filippo Valsorda
- Slides: Pruning MTC
- Filippo demonstrated that MTC is modular. By setting the subtree size to one and using standalone certificates without cosigners, MTC becomes isomorphic to a standard X.509 signature (e.g., "MTCDSA").
- This "degenerate" case allows private PKIs or constrained environments to use the same PQ-capable code path as the Web PKI without the overhead of transparency logs or interactive landmark protocols. Features like audit logs and cosigning can then be added back as needed.
Decisions and Action Items
- GitHub Policy: The working group will adopt "Issue Discussion Mode" for GitHub. This will be confirmed on the mailing list.
- Terminology: The names "standalone certificate" and "landmark certificate" were accepted by the room.
- Draft Splitting: The authors will begin the process of splitting draft-ietf-plants-merkle-tree-certs into the core protocol document and an architecture document.
Next Steps
- Architecture Document: Initial drafting and scope definition for the architecture deliverable.
- Log Generations: Continued discussion on the mailing list regarding the maximum number of generations and enforcement by relying parties.
- Private PKI: Based on interest from Viktor Dukhovni, Deirdre Connolly, and John Gray, the group will further explore how MTC applies to client certificates and private/internal PKIs.
- External Coordination: Coordination with the TLS, ACME, and LAMPS working groups regarding Trust Anchor IDs and certificate negotiation.