On Feb 8, 2021, at 10:01 AM, Jim Reid <[email protected]> wrote: > > > >> On 8 Feb 2021, at 17:11, Paul Hoffman <[email protected]> wrote: >> >> Without a fleshwd-out proposal for a fully-authenticated protocol to compare >> to, saying that this WG should not try to fulfill its charter to help >> encrypt recursive to authoritative traffic just seems wrong. > > Paul, just because the WG *can* choose to do something doesn’t necessarily > mean it *should*.
Quite right. My response was to the assertion that the WG should stop work altogether without being able to consider what a hopefully-future proposal for fully-authentication encryption would entail. > I’m not convinced there’s much to be gained from encrypting > recursive-to-authoritative DNS traffic. That certainly depends on the definition of "much", but I am assuming that the WG already chose this when it considered the charter. Are you proposing that we re-open the charter again? (I kinda hope not, but would understand if folks want to think about how much value there would be to doing this work.) > Or that this will ever get deployed at scale. It is by definition easier to deploy opportunistic encryption than fully-authenticated encryption for both resolvers and authoritative servers. > Have the use cases and requirements been documented for the problems this ID > is intended to solve? Yes, in the draft itself, since the first version. If they are not clear or are incomplete, I would certainly want to hear about it. > However my main concern are the unintended consequences from the standards > track(?) RFC that eventually emerges. That could get baked into RFPs for DNS > service or ICANN registry contracts, creating major operational and > deployment problems for anycast providers who’d be on the hook for servicing > bazillions of presumably encrypted queries per second. Again, that would inherently be more onerous for fully-authenticated encryption. But if you are concerned about RFPs and contracts in general, a discussion of that should be added to the eventual protocol document. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
