On Fri, Oct 1, 2021 at 8:07 AM Paul Hoffman <[email protected]> wrote:
> On Oct 1, 2021, at 4:50 AM, Brian Haberman <[email protected]> > wrote: > > > > On 9/23/21 2:17 PM, Ben Schwartz wrote: > >> > >> I think this clarifies an important requirements question for the > working > >> group: do we intend to enable authenticated ADoT for names whose TLD > >> doesn't do ADoT? If yes, we need a way to authenticate the NS name and > a > >> signal for ADoT support. If no, we can rely on the parent's ADoT to > >> authenticate the glue (as suggested in draft-adox). > > > > I purposely waited a week to see if anyone would venture an answer to > > this query. From my perspective, as co-chair, the lack of an answer is > > quite telling. To me, it indicates that the WG is still not sure where > > it wants to go with this work. > > If "this work" means authenticated ADoT, I agree. If "this work" means "DS > glue", I disagree. The presence of DS glue for resolvers that are doing > unauthenticated DoT allows for more encryption of DNS on the Internet. > Is there a document on the requirements for unauthenticated DoT, or a comparison of things ADoT offers that unauthenticated's use case could be handled by just ignoring some of those ADoT features? As for "DS glue" (specifically the draft in DPRIVE with that name), there is a vaguely similar draft by me in DNSOP that does a similar single thing that is slightly similar to ds-glue, where the differences are important. The "one thing" in the DNSOP draft is "supply DS record(s) that correspond to NS records present at the parent, via new DNSKEY algorithm and existing DS hash algorithms, intended to only validate/verify the published NS records in the parent". This is consistent with the general policies related to ICANN TLDs and use of DNSSEC records (which validate/verify delegations and do not do anything else that impacts TLD policies, which I believe are generally mandated by ICANN under Registry contracts. What "DS glue" is proposing seems to me to be a significant departure from existing TLD usage and policies, in particular publishing new DATA in the DS records that preempts existing published data, using new DS algorithms that the TLDs all need to support for it to be useful. My concern is that the relationships between the larger organizations (IETF, ICANN, Registries), where there are formal channels for asking questions and proposing changes, may require obtaining permission in advance of proposing significant policy changes. I'd suggest that the authors and chairs discuss this with the AD, IESG, and get a read on this from the IAB. There may be a need to consult with various liaisons or via liaisons to the other organizations, to determine if this is okay to do without any actual changes to official policy documents, or if it would require policy level changes. At a minimum, even without the liaison work, getting an informal buy-in from the major gTLD registry operators is a crucial step. Brian Dickson > > > I would contend that the only consistent > > view I have heard from everyone is that there is not a need to > > authenticate or encrypt to the root servers. After that, I see a lack of > > consensus on: > > > > 1. ADoT support at TLDs > > 2. ADoT support at parents for children doing ADoT > > > > Granted, in most cases #1 is a degenerate case of #2. > > Given that, can we move forward with the unauthenticated use case, for > which there has been a lot of interest? Or do we have to reach consensus on > one use case for both of them to move forward? > > --Paul Hoffman_______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
