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]
