On Mon, Sep 29, 2025 at 03:42:37PM -0700, Aaron Gable wrote: > I support adopting this draft.
I also support adopting this draft, noting that adoption is as a starting point for future evolution -- the overall structure here seems worth pursuing but probably needs further refinement (and definitely needs more security considerations to be discussed, even though the current content is admirably in-depth). > But beyond that, I think that this *solution* space is quite interesting, > and worth discussing as a Working Group. The key insight is that, because > ACME accounts are tightly bound to keypairs, ACME account URLs can be > durable and cryptographically-bound stand-ins for random tokens. Both this > method and the existing dns-01 show the same thing: the DNS operator > approves of the operator of a specific ACME account. > > Of course, there's one hiccup: they actually only show *almost* the same > thing. The dns-01 method shows that the DNS operator approves of the > operator of a given ACME account (the one to which the random token was > sent) *right now*. The proposed dns-persist-01 only demonstrates that the > DNS operator approved of the ACME account *at some point in the past*. Yes, one key property of dns-01 and the other initial set of challenges is that they had a random token that bound the authorization to the specific requested issuance, and by necessity we need to relax that requirement in order to achieve a persistent validation at all. But that tight binding and the single-use property of the challenge token improved the security properties of the authorization process and left us in a reasonable position even in the absence of DNSSEC. When we want a persistent challenge/authorization where the content is entirely (mostly) predictable, additional considerations creep in and the CA has a stronger burden to verify the authenticity of the DNS response since there is not a single-use token to perform that authenticity verification. That is to say, I agree with the proposal in a different thread to require the use of a DNSSEC-validating resolver, since we are placing fairly strong requirements on the DNS transport to preserve the authenticity of the provided records, and if the domain owner elects to use DNSSEC to provide a stronger authenticity guarantee for their domain's records we need to respect that choice. Other security/privacy considerations to pull in include: - revealing the accounturi in public DNS makes public some linkage of account and domains that are not necessarily otherwise visible (though I guess CAA itself does some similar things). - I may have missed something key, but in the scenario where the DNS zone gets compromised an attacker can introduce a very-long-lived persistent validation, we need to consider what bounds the length of that validation and whether/how the rightful domain owner can invalidate that validation. I.e., just removing the fraudulent record may not suffice and we may need a way to "cancel" a previous validation, or a protocol-level cap on the duration of time for which a validation record is valid. > But while I think that distinction is critical and worth discussing > extensively, I don't think it is disqualifying. In particular, I think that > the tradeoff here -- less proof-of-freshness in return for massive > operational simplification -- will result in large uptake of this > validation method and a large improvement to the security and privacy of > the web overall. This (large uptake and large security/privacy improvement) I am less sure about, but I agree that we should have the discussion and try to figure out where the tradeoffs arise. I personally admit the possibility that the tradeoffs will end up being such that we end up not wanting to publish after all, but there's a good chance that it will provide value and be worth publishing. -Ben _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
