Re: [DNSOP] Working Group Last Call for "Domain Verification Techniques using DNS"

[Shivan Kaul Sahib <[e-mail]>]

I think Paul conveyed the authors' opinions here pretty well. Just wanted
to respond to the token generation bit:

On Fri, 17 Feb 2023 at 08:22, Paul Wouters <[e-mail]> wrote:

> John Levine wrote:
>
> > While I think it would be good to publish some best practices in this
> area,
> > this draft still seems scattered and makes some assertions that seem to
> me
> > to be somewhere between unsupported and mistaken.
> >
> > I think we agree that the goal is there are two parties, call them
> > owner and verifier, and the verifier gives the owner a random token
> > that the owner puts in its DNS to show it owns the domain.  There are
> > a bunch of different aspects that one can look at independently.
>
> Two (or three) parties yes.
>
> > One is where the token goes, in the name or contents of the owner's
> > record. I think we agree that putting the token at the owner's host
> > name is a bad idea, but either of these can work, with a1b2c3 being
> > the random token:
> >
> > _a1b2c3.example.com IN ... "whatever"
> > _crudco.example.com IN ... "a1b2c3"
>
> Adding cryptogrpahically strong/long strings in the prefix seems
> unwieldly and prone to problems - especially if the user has to put
> these in via a webgui of mediocre quality. Also it makes manual
> checking harder (eg to use the dig command). But most importantly, you
> already need a good prefix to identify the vendor and service and
> mucking up random strings there just seems the wrong thing to recommend
> as BCP. So the only good reason for these is if there is a 3 party
> system (vendor/service, client, proof-provider)
>
> > If you use a fixed prefix, _crudco in this case, you should register it
> > in the RFC8552 attrleaf registry.
>
> Since we are recommending these are easilly recognised to vendor and
> service, these would be different for each vendoer. Sure, we can add
> another prefix in between and put that in the attrleaf registry, but
> that doesn't add any real value.
>
> > Another is what record type to use. I find the arguments against CNAME
> > unpersuasive, basically saying that if you do something dumb, it won't
> > work, which is true, but it's always true.
>
> I thought a BCP was about recomending people don't do dumb things?
>
> > I realize that RFC1034 says
> > not to chain CNAMEs, but we all know that people chain CNAMEs and it
> > works, e.g. www.microsoft.com goes through three CNAMEs and it works
> > fine.
>
> I was not allowed this line or argumentation with you when talking
> about the LHS of an email address :)  So let's stick with not
> recommending things that violate existing RFCs?
>
> > If you use a _name in the attrleaf registry or a _random prefix
> > I would think the changes of a CNAME colliding with something else are
> > low, and a verifier presumably controls its own DNS and can keep CNAME
> > chains short.
>
> People make mistakes with CNAMEs, let's not recommend CNAMEs so chances
> that people get affected my mistakes is reduced.
>
> > For the length of time the token is valid, there seem to be only two:
> > five minutes for a one-off verification like for ACME, or forever for
> > someone who is doing continuing analysis of something in your domain
>
> Five minutes seem optimistic and only true for geeks running their own
> webserver and nameservers. In real life, you have different departments,
> timezones, ticketing system response times, etc. So these things will
> stay in the zone for days or as we often see now, forever, because
> people like to error on the side of "I didn't cause that outage" over
> "I cleaned up our DNS".
>
> > typically web analytics. While I can see aesthetic reasons to get rid
> > of expired one-off tokens, I don't see the point of putting an
> > expiration time in them, nor any particular harm in leaving them there
> > if they are at _name and not the main host name.
>
> You might be missing operational experience in working in larger
> companies. For example, when I started current $dayjob, I found 7
> records and 4 of these could not be traced as to who needed them or
> whether they were still needed or not. Some "digging" around showed
> us cases where large companies had 20+ entries in their APEX related
> to these. So yes, cleanup is very imporant and one of the main
> reasons for this BCP - to faciliate cleanup of records by getting
> them issued in a better self-documenting syntax.
>
> Yes, using/recommending prefixes helps us, which is why we recommend
> them. But having an expiry is also obviously useful for cleanup.
>
> >From a security point of view, it is also good to know that a certain
> record has no more value so your audit reports can state no access
> of some kind was given via some DNS record 10 years ago and might be
> still in place but we dont know if the vendor still honours the record
> of whether it is expired and just junk.
>
> > something about TTLs, e.g., not to have a 12 hour TTL for a token you
> > plan to remove in a few minutes.
>
> We could say something about TTL, but here I really don't see much
> point. Having 1 TXT record in some recursive cache for 12 hours? Meh.
>
>
> > There are some other minor points. You say to generate 128 random
> > bits, but then to hash them to 256 which I don't understand. (As RFC
> > 4086 sec 6.2 notes, strong random bits often are already hash output.)
> > If 128 bits is enough, use 128 bits, if you need 256, generate 256.
> > Either way I'd do base32 rather than base64 encoding to make the
> > result more robust against helpful software that does you a favor by
> > case folding.
>
> We will look and clarify this section.
>

I created
https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/pull/44
to clarify this.

>
>
> > Overall, I'd lay out the options, and point out the advantages or
> > disadvantages of each rather than just saying "do this" without a
> > strong basis not to do it the other ways that work fine in practice.
>
> I disagree about there being a lack of "strong basis". This is actually
> driven by people's operational (bad) experience at various
> organizations. Giving people CNAME rope to hang themselves or unwieldly
> long random prefixes seem to be bad ideas that should not be recommended
> nor "explained but not recommended" either.
>
> Paul
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>