On Feb 8, 2021, at 14:02, Paul Hoffman <[email protected]> wrote: > > 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.
PaulH is right on this. The problem statement and charter is clear. Whether we can find an acceptable solution that will lead to widespread deployment with the right minimum security properties is what’s under discussion. >> 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. Very marginally easier and at an expense of clarity and simplicity. >> 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. IETF is not the protocol police. We make standards people can choose to use. If others make these standards contractual requirements then you should raise those concerns there, not here. Our concerns here should be things like feasibility, deployability, operating cost etc. Perhaps our protocol will have an optional seat belt, and perhaps ICANN will require seatbelts. Then talk to ICANN. Paul _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
