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 <p...@nohats.ca> 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 > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
