Hi ACME! [Chair hat on]
I have reviewed the call-for-adoption discussion on-list, and there is unanimous consensus to adopt, so it is adopted. Authors, please submit a draft-ietf-acme-dns-persist. There seems to be less consensus around the urgency and content. On one hand, there is desire to align the content and timing with the parallel ballots in CA/B F, and the authors note that there is implementation intent from at least Let's Encrypt if not also other ACME CAs, as well as a viable "no RFC" deployment option if standardization takes too long. On the other hand, the IETF WG wants to take the time to evaluate the solution space more broadly. My recommendation would be for the authors to take a strong hand in setting the tone for timeline and technical content, and advise the WG on this in Montreal. For example, if this is already being deployed in open multi-vendor environments, then there is value in simply documenting that in an RFC, and that could move fairly quickly. Alternate designs can be proposed in additional drafts. On the other hand, if the implementations are still flexible and the implementers are willing to engage in an IETF design process, then we can afford to slow down. I encourage the authors to canvas the implementer community and report back to the WG in Montreal. (I suppose this last comment is as much a question to Aaron as it is to the draft authors). As a personal [no-chair-hat] comment, I agree with Ben Kaduk's analysis that we need to do a good job on the Security Considerations because one-time-use tokens are naturally immune to all sorts of attacks, but in moving to a persistent token model, we'll need to consider the attack surface introduced by persistent tokens, most of which will come down to documenting the risks that operators incur by switching to this model, and choosing an appropriate validation reuse period. On Fri, 10 Oct 2025 at 15:42, Benjamin Kaduk <[email protected]> wrote: > On Fri, Oct 10, 2025 at 01:37:31PM -0700, Aaron Gable wrote: > > I believe what Benjamin was talking about was the concept of "Validation > > Reuse", wherein a single DNS query returning a validation record can then > > be re-used by the CA for an extended period of time, regardless of the > TTL > > on that record. The CA/BF Baseline Requirements currently cap that > > Exactly so. (And even if the CA respects the TTL the TTL could be > maliciously lengthened, as Ilari noted.) > > > validation reuse period at 398 days, with a timeline to crank that reuse > > period down to just 10 days by mid 2029. > > > > I think that considering validation reuse periods is an important topic > to > > cover in the Security Considerations, and something which should be > > addressed at the PKI policy level, but not necessarily something that > > should be baked into the normative text of this IETF document. > > Yes, I was insisting on some discussion in the security considerations, but > merely soliciting discussion on what (if any) hard protocol requirements we > need to include. > > Thanks for helping clarify, > > Ben > > > On Fri, Oct 10, 2025 at 11:47 AM Ilari Liusvaara < > [email protected]> > > wrote: > > > > > On Fri, Oct 10, 2025 at 10:47:53AM -0700, Benjamin Kaduk wrote: > > > > > > > - 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. > > > > > > Deleting the record (which someone with zone control can do) cancels > the > > > validation, no matter how long-lived the validation is? > > > > > > The only thing I know that would behave anything like that is setting > > > very long DNS TTL. And bad records with very long TTL are not a new > > > problem: For example, records with long TTL pointing to hijacked > > > nameservers. > > > > > > Resolvers can cap the DNS TTL. AFAIK, Let's Encrypt caps the TTL to > > > 1 minute. > > > > > > > > > > > > > > > -Ilari > > > > > > _______________________________________________ > > > Acme mailing list -- [email protected] > > > To unsubscribe send an email to [email protected] > > > > > _______________________________________________ > Acme mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
