On Nov 1, 2025, at 18:18, Erik Nygren <[email protected]> wrote: > > I've created a pull request with alternate text: > > > https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/202/files > [github.com] > > It replaces the guidance on "MUST be 128 bits" with: > > One way of constructing Unique Tokens is to use random values which: > 1. have adequate entropy to guarantee uniqueness and ensure that an attacker > is unable to create a situation where a collision occurs. > [...] > > To the Token Collisions security considerations it adds the second two > paragraphs to: > > ## Token Collisions If token values aren't long enough, lack adequate > entropy, or are not unique there's a risk that a malicious actor could obtain > a token that collides with one already present in a domain through repeated > attempts. > Application Service Providers MUST evaluate the threat model for their > particular application to determine a token construction mechanism that > guarantees uniqueness and meets their security requirements. > When Random Tokens are used, they MUST be constructed in a way that does not > have collisions and is not predictable (see {{RFC4086}}). > Does this seem better? Would we want to provide any guidance on minimum size? > As you point out this varies widely based on the application and its threat > model. > > I did not introduce a formal threat model section --- that seems like a much > larger addition > if people feel that it is needed.
Either you have to describe the attack before you describe how to mitigate the attack with cryptographically strong keys, or you need to remove the un-supported mitigation. I propose you do the latter because the rest of the draft works just fine with on-path attackers for everyone other than those who need cryptographically strong keys (namely certificate authorities). Said another way, if this draft is really about domain control validation for everyone, and only CAs care about that attack, don't even list it. It is safe to assume that any CA doing ACME understands the issue. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
