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

Reply via email to