Eric, Thank you for taking the time to review the draft. Your review did exactly what a good early review should do: it forced me to separate what the design actually contributes from how -00 chose to sell it. The result is -01, which is substantially restructured. The submission tool is closed for the pre-meeting blackout, so I'll post it to the datatracker on July 18 when the tool reopens; the preview text is previewable now at:
https://github.com/braid2026/BRAID/blob/main/draft-davey-tls-braid-01.txt Rather than defend -00, let me explain what changed and why, point by point. 1. "You didn't remove the automation; you moved it." Agreed, as -00 was framed. The -00 text led with freshness and certificate lifetime, which made the proposal read as "renew some other evidence instead of renewing the certificate" -- and on that reading your objection is correct and fatal. Working through the design again made clear that the security property never actually came from the freshness cadence. It comes from a membership check: the owner's DNSSEC-signed Anchor lists which Delegated Credential public keys are authorized, and the client checks that the handshake key is in that list. That check holds with a completely static Anchor and a long-lived credential key. So -01 defines the baseline (BRAID-Base) with no DNS-side automation and no CA-facing automation at all in steady state: the Anchor is written once and touched only to rotate or revoke, and the credential key can live indefinitely. To be precise rather than oversell: RFC 9345 caps the credential *object* at seven days, so there is one recurring operation -- re-signing a credential over the same key pair with the EE key the operator already holds. But that operation is local and self-contained: no CA interaction, no domain validation, no rate limits, no DNS write, pre-computable, and it fails visibly on the operator's own hardware rather than at a third party. That's a different operational posture from must-staple, where the fresh evidence came from a responder the operator didn't control -- which is exactly why must-staple soft-failed and died. And it's the general shape of the answer to "you just moved the automation": the two automations aren't the same kind of thing. An Anchor update or a local re-sign is an owner-scheduled job against infrastructure and keys the owner controls; a certificate issuance is a transaction with an external party, on that party's API availability, rate limits, validation requirements, and commercial terms. Moving recurring work from the second category to the first is a real operational change even where the count of cron entries is unchanged. Freshness survives in -01 only as an optional profile (BRAID-Agile) for operators who want to bound stolen-credential-key exposure and revocation latency, and it's labeled as exactly that: a latency/exposure bound, not the source of the security property. On the dual-burden point: also conceded, and now stated as an explicit non-goal. While non-BRAID clients exist, the operator keeps its conventional short-lived certificate and its existing ACME automation, unchanged. -01 doesn't claim lifetime relief as the value proposition at all; the value at prevailing lifetimes is stolen-EE-key defense, CA-compromise defense, owner-controlled selective de-authorization, and name-scoping for delegated credentials handed to CDN edges. 2. DNSSEC and client-side validation. The -00 resolver story was too vague, and vague trust models in this space have a bad track record, so -01 replaces it with two explicit, non-substitutable modes. Public-Web strict mode never trusts a resolver's AD bit: the verifier validates self-authenticating proof material -- cached, hash-referenced, stapled, or shipped as an authenticated snapshot with the client, the way HSTS preload and CRLite-style snapshots already ship today. Managed-Resolver mode is for enterprises and managed endpoints that deliberately place a validating resolver in their TCB over an authenticated channel. A policy requiring the strict mode cannot be satisfied by the weaker one. This doesn't make public-web deployment easy, and I'm not claiming it does; it makes the trust model explicit, and it's why the deployment ladder now starts with a monitor-only mode that requires no client behavior at all and is independently useful (it catches credentials serving traffic that the owner never authorized -- a signal CT can't provide). Second-impression security via the policy record remains what it is; preloading is the answer for domains that can't accept the first-contact residue, and -01 says so plainly. 3. The OCSP/must-staple isomorphism. The distinction -01 draws is state vs. status. The Anchor is authorization state in the owner's zone, not a per-connection status assertion: nothing is fetched from a third party per connection, and -01 now prohibits per-connection third-party status queries as a prerequisite for strict validation. Proof material moves by hash-verified reference with client caching, and in the base profile it changes only when the owner rotates or revokes. Where must-staple coupled every operator's availability to a CA responder, the only party whose infrastructure can fail here is the owner -- which is a risk reassignment, and -01 argues it's the right one, since the owner is the party with both the power and the incentive to manage it. Relatedly, -01 deletes -00's graceful-degradation option for the Identity strand entirely: strict mode fails closed, full stop. I'd rather defend fail-closed honestly than be correctly accused of shipping soft-fail under a new name. 4. TLSA usage 1 with the EE certificate. This one deserves the most precise answer, because the two mechanisms look equivalent until you ask what object the record vouches for. TLSA usage 1 binds the DNSSEC name to the EE certificate or key. That's real value against mis-issuance by another CA. But against a stolen EE key it does nothing: the attacker presents the same certificate and proves possession of the same key the record authenticates -- the record vouches for exactly the object that was stolen. The same holds for usage 3. BRAID's Anchor authorizes a different object: the credential key, one delegation step below the EE key. A thief with the EE key can mint a syntactically valid RFC 9345 credential, but can't put that credential's key into the owner's signed zone. So impersonation requires the EE key *and* the owner's DNS publication path -- a two-control condition TLSA can't express, because TLSA has no way to authorize a key other than the one in the presented certificate. Your revoke-by-withdrawal variant also behaves differently in the two designs. Withdrawing a TLSA record hits the attacker and the legitimate service identically (same cert, same key), so revocation is also self-inflicted DoS -- and it only means anything to clients that treat absence as fatal, which needs a separate "TLSA required" signal, or absence just means "not deployed" and clients fall back to plain PKIX. BRAID carries that requirement signal in the certificate itself as a critical extension (which is also why it has to be negotiated), and revocation is selective: remove the stolen key's Anchor entry, keep serving on another authorized key. No outage. On the deployment inference: I'd argue TLSA-for-web's non-deployment reflects its specific bundle -- contested marginal value over WebPKI (per the stolen-key analysis above) plus in-band client DNSSEC with an implicit trust model. -01 changes both terms: the marginal value is the two-control property, and the trust model is explicit and staged, starting from a mode with no client involvement. That may still not be enough to get deployment -- fair -- but the inference from TLSA's history doesn't transfer cleanly. Structurally, -01 also narrows the ask: Routing and Witness moved to future extension profiles with the work split across LAMPS/DNSOP/ SIDROPS/TRANS named in an appendix. The two aren't symmetric, and -01 says so: Routing waits on a validated-origin query that doesn't exist yet, while Witness has no missing dependency and is deployable in managed environments today, so a short companion draft specifying the Witness profile (co-signing format, witnessed freshness, independence and appointment-terms requirements) will follow separately rather than riding along in the TLS document. The five-year validity text is gone (validity is root-program policy, out of scope, and the document must be useful at prevailing lifetimes), Anchor placement got deterministic location/multi-SAN/wildcard rules, and there's now a normative validation algorithm plus ten negative test vectors, starting with the stolen-EE-key case and including a TLSA usage 1 control case, which we intend to exercise in a monitor-only implementation first. The diff is large but the direction is the one your review pointed at: smaller claim, sharper property, honest trust model. I'd welcome another pass whenever you have time, particularly on the two validation modes in Section 9 and the TLSA comparison in Section 5 -- if the distinction there doesn't hold up under your reading, that's the load-bearing wall. I'm also posting a summary of the -01 changes to the TLS list this week, ahead of the July 18 submission. Happy to credit your review by name or refer to it as off-list review -- whichever you prefer. Thanks again, George From: Eric Rescorla <[email protected]> Sent: Monday, July 6, 2026 9:33 AM To: George Davey <[email protected]> Cc: [email protected] Subject: Re: [TLS] New draft: BRAID — multi-strand certificates with structural revocation (draft-davey-tls-braid-00) EXTERNAL ________________________________ Document: draft-davey-tls-braid-00.txt George, I've given this a quick look. The TL;DR is that I do not think that this is a viable proposal, for several reasons. The most important reason is that I don't think it really addresses the operational issues that people have with short-lived certificates, which mostly have to do with the need to automate renewal. In this design, you still need to automate renewal, not of the certificate itself, but of the rest of the evidence (the DC, witnesses, etc.). It's not clear to me why this is any better. Moreover, as long as this is not universal (which strikes me as very unlikely), peeople will still have to use short-lived certificates for clients which don't support BRAID, at which point they have both operational burdens. Second, this seems to me to have a number of technical drawbacks that have appeared with other related mechanisms. Specifically: - Like TLSA, it depends on DNSSEC, and as a practical matter requires client-side validation. This is already something we know that end-user clients have no appetite for, and what measurements we have indicate that failure rates will be unacceptably high. I know you mention an HSTS-like mechanism, but this only provides reasonable security on second impression, which isn't very good for something this heavyweight. - Because you have to deploy supplemental (non-certificate) data, you have the problem of either updating the server to serve it (roughly isomorphic to OCSP stapling and must-staple) or serving it from some other public endpoint (roughly isomorphic to OCSP). This seems likely to have the same problems we have seen with those mechanisms. Finally, I would note that you could achieve at least some of the properties you are proposing here with existing mechanisms. Specifically, if DNSSEC *is* viable as a means of serving this kind of information, then you can simply use TLSA directly with the EE certificate with certificate usage 1, and then just stop serving the TLSA record directly. This is much simpler than what you are proposing and is at least conceptually available now, so the fact that it is not widely deployed suggests that BRAID will also not be widely deployed. -Ekr
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
