I've created a pull request with alternate text:
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/202/files 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. Erik On Mon, Oct 20, 2025 at 12:19 PM Paul Hoffman <[email protected]> wrote: > On Oct 17, 2025, at 09:04, Tim Wicinski <[email protected]> wrote: > > We asked for agenda time in Montreal, but barring that we'd like to hear > what is still outstanding. > > Section 5.1.1.1 is still way too prescriptive, and makes it impossible for > random tokens to be typed by a user. In Section 5.1.1., the use case for > unique tokens says "adequate uniqueness so as to guarantee a causal > relationship between its issuance and its appearance in a DNS record". Even > 30 bits of randomness (1 in a billion) is sufficient for that in many > cases. The reference to RFC 4086 is also irrelevant to many use cases > described in Section 5.1.1. > > I propose that either Section 5.1.1.1 be removed or, if the WG thinks that > this needs to be shown, it should be expanded to an example of using a > 10-digit number. > > --Paul Hoffman > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
