There are some benefits in ACME for it being on the label (At least in the ACME use case):
It being on the label provides external confirmation that the ACME server did the correct thing. If it's part of the response, it's a lot easier for an ACME server to falsely claim the scope was something other than what the client had set it to. The downside of it being up to three lookups doesn't apply to the ACME use case. The specific query that is going to be looked up has been described in the order object (wildcard, subdomain, or just host), so the ACME server will only be looking up one of these. The main reason we really brought the scoping model to the DNS-ACCOUNT (now SCOPED-DNS-CHALLENGES: https://datatracker.ietf.org/doc/draft-ietf-acme-scoped-dns-challenges/) was the verifiability of behavior we get out of it. If we move this out of the qname, then someone can challenge us by saying what do we get out of this that we can't get with CAA. On Mon, Feb 19, 2024 at 7:56 PM Shumon Huque <shu...@gmail.com> wrote: > On Mon, Feb 19, 2024 at 6:55 PM Paul Wouters <p...@nohats.ca> wrote: > >> On Sat, 17 Feb 2024, Shumon Huque wrote: >> > I'm sure other folks will chime in with their views. But I want to ping >> Paul Wouters specifically - since you are one of >> > the expert reviewers for this registry and an author of >> domain-verification, could you express your opinion on the >> > specific request related to ACME (a pre-existing entry in that >> registry) and its new scoped challenge specific labels. >> >> That registry is really weak. first come first serve. In theory, I >> wouldn't technically be able to stop someone else from registering >> _acme-elvis-my-way-challenge. >> >> The main goal of the registry is to avoid people inadvertently using the >> same name. As such, I might push back a little on very generic names, >> but things which clearly carve a namespace for general use like _acme, >> are fine. >> > > Thanks! > > >> Now speaking as author, not as the underscore registry expert: >> >> I'm not sure you would want the host/wildcard/domain difference in the >> QNAME though, because that might end up needing 3 DNS queries to find >> out. It would be best if things could come in with 1 DNS query. Make >> the variable part live in the RRdata, not the QNAME. >> > > Yup, I agree that would be better. The DCV draft already has other > examples of expressing application specific characteristics in "name=value" > attributes of the resource record data (such an "expiry" attribute). > > Perhaps, we can propose a "scope=" attribute, that can take on the > 3 possible values of host/wildcard/domain. e.g. > > _acme-challenge.www.example.org. 300 IN TXT "gfj9XqxxxxxxRg85nM > scope=wildcard" > > or, > > _acme-challenge.www.example.org. 300 IN TXT "gfj9XqxxxxxxRg85nM" > "scope=wildcard" > > Eric (Nygren) - was there a compelling reason to encode the scope into > the qname label? Otherwise, I'm inclined to propose this change in > the draft. > > Shumon. > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
