IETF protocol updates on EST, DKIM PQC, and timestamp security

IETF working groups spent the day on concrete protocol friction: EST channel binding under TLS 1.3, post-quantum DKIM design choices, IPv6 RIO edge cases, and tighter EKU rules for timestamp authorities. Several drafts nearing adoption or AUTH48 drew implementer and chair input on deployment reality versus cryptographic purity.

EST and tls-unique under TLS 1.3

LAMPS revisited RFC 7030 Enrollment over Secure Transport and the tls-unique channel binding that does not carry cleanly into TLS 1.3. Chairs and implementers leaned toward dropping the binding rather than carrying forward deployment friction, which would simplify EST clients and servers that already struggle with the older mechanism. Readers maintaining certificate enrollment stacks should watch for a formal deprecation path.

DKIM2 post-quantum threat model

The IETF DKIM list continued a lengthy exchange on ML-DSA algorithm choices, multi-signature semantics, and the DNS record changes needed for DKIM2 PQC support. Participants weighed threat-model statements against operational cost of larger signatures and key material in DNS. Mail operators and library authors face early design decisions that will shape how quickly PQC signing can ship without breaking existing verifiers.

IPv6 RIO length ambiguity near AUTH48

A 6man draft updating RFC 6724 drew discussion of ambiguous handling when Router Advertisement RIOs are longer than /48 for ULA known-local entries. The thread seeks clearer rules before the document finishes AUTH48. Host and router implementers relying on known-local ULA logic need the resolution to avoid inconsistent source-address selection.

Tightening RFC 3161 timestamp EKU rules

A new Housley draft proposes stricter Extended Key Usage constraints in RFC 3161 so timestamp authorities cannot reuse keys across protocols in ways that enable cross-protocol attacks. The change targets a known class of key-confusion risks rather than adding new algorithms. Operators of TSA infrastructure and CMS verifiers have a concrete hardening path under review.

Privacy Pass reverse-flow draft adoption

The Privacy Pass working group discussed next steps for adopting draft-meunier-privacypass-reverse-flow, with the chair noting a possible later move into a new MOLE WG. The draft addresses token flows in the reverse direction from the base protocol. Privacy-preserving auth implementers should track whether the work stays in Privacy Pass or relocates.

NANOG flag on AS47528 and PHP RCE traffic

A single NANOG post reported unusual traffic from AS47528 (PITERIX-AS, RU) that may indicate exploitation of newly disclosed PHP remote code execution flaws. The note is observational rather than a full incident report. Network operators can treat the ASN as a temporary signal while correlating with their own PHP-facing telemetry.

NTPv5 server identification and amplification

NTPv5 discussion focused on extension-field sizing and truncation for server or node identification so that larger identifiers do not create amplification risk. Participants sought operational use cases that justify the fields without reopening classic NTP DDoS vectors. Time-service operators evaluating NTPv5 drafts gain clearer bounds on what identification data can safely appear on the wire.

FrodoKEM CMS conventions call for adoption

LAMPS opened a call for adoption of draft-chen-lamps-cms-frodokem-01, covering CMS conventions for the ISO-standardized FrodoKEM algorithm, with early responses positive and the call ending 2026-10-28. The work gives implementers a concrete encapsulation path inside existing CMS messages. Cryptographic library and S/MIME developers have a short window to register support or objections.