Paul Wouters proposed that we drop the 4086 reference and instead say:
"When Random Tokens are used, they MUST be constructed in a way that
provides sufficient unpredictability to avoid collisions and brute force
attacks."
This is in addition to the text "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."
Does that cover your concerns?
It's not just CAs who have security requirements around DCV. As an
example, SaaS providers using it to link the enrollment of domains to
customer accounts may care heavily around security, but the details of
their threat model will be specific to their application.
Erik
On Sun, Nov 2, 2025 at 7:54 AM Paul Hoffman <[email protected]> wrote:
> 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
>
>
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
