On Mar 4, 2019, at 5:44 PM, Paul Wouters <p...@nohats.ca> wrote: > > On Mon, 4 Mar 2019, Ray Bellis wrote: > >> This new draft describes a way for clients and servers to exchange a limited >> amount of information where the semantics of that information are completely >> unspecified, and therefore determined by bi-lateral agreement between the >> client and server operators. > > This makes me very nervous. An edge ISP DNS server could use this to > mark DNS packets from certain users, and applications could use this as > another cookie to track users, especially in light of endusers talking > directly to open resolvers like the Quads, from within the application, > bypassing the operating system.
As the draft says, they can already do this now with unassigned EDNS0 code points. There is nothing you can do about it. >> There are known cases where bespoke implementations are using experimental >> EDNS option values for this purpose, for example for a front-end >> load-balancer to tell the server whether an incoming connection arrived over >> TCP or UDP (c.f. my XPF draft). > > Great. And once experimenting is done, submit a draft and get a real > EDNS code point. Do this as many times as you want. The idea of a > limited experimental space is that you cannot rely on it to be rolled > out into the wild word. That's a feature. Or a bug. IETF WGs cannot agree on which it is. Some WGs cannot remember which they prefer from year-to-year. >> A goal of this draft is to assign a common EDNS code-point such that popular >> OSS implementations can support similar features interoperably. > > I would much rather see 10 specfic EDNS code points for features, than a > kitchen sink EDNS option that can be abused to send potentially > dangerous tracking identifiers that we cannot distinguish from actual > DNS infrastructure options. That's a fine preference, but it does not align with the reality that anyone can already do that. Not having a standard doesn't prevent abuse. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop