Thanks for this helpful input! (In theory DNSSEC could prevent falsified responses about scope, but I realize that it's not widely deployed :(
Let's also think about the more general (non-ACME) application use case too. Maybe multiple possible ways to indicate scope are needed. Shumon. On Tue, Feb 20, 2024 at 11:48 AM Amir Omidi <a...@aaomidi.com> wrote: > 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
