Greetings again. draft-ietf-dnsop-domain-verification-techniques talks in many places about random tokens. Section 5.1.1 mixes up "unique tokens" and cryptographically secure random tokens, including having MUST-level requirements that are inappropriate.
If an ASP wants to be sure that a particular user has control of a domain, it may be better for them to tell the user to put that user's ASP-associated name in the token because then the ASP doesn't have to store a long-term association between the user and the random value. Thus, the token is really not random, but is in fact unique for the site. Worse, Section 5.1.1 says that the random value must have 128 of entropy, even though the use case for DCV described in Section 3 has absolutely nothing to do with randomness. To be unique, the token can have a 32-bit number (assuming that the service doesn't have more than 4 billion users...). The implications of "random" will make the other good proposals in the document less likely to be implemented correctly. I propose that the document consistently use the term "unique token" throughout, that section 5.1.1 be rewritten to be about uniqueness, and the text in that section be amended to say "if you want, a good way to generate unique tokens is to pick random values and then encode them this way". This way, we will be describing a best practice (using a token) and telling the reader multiple ways to do so. I'm happy to propose specific text changes in the repo if the WG agrees. --Paul Hoffman _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
