On Tue, 5 Mar 2019, Paul Hoffman wrote:
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.
We can not facilitate those practises by not giving these practises a
code point ?
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.
Well, it seems we have a registry for EDNS code points with
experimental/local code points. So I'm not sure how your
comment relates to this or other WGs?
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.
Sure, but facilitating those general purpose meta-camels is also not required
action of the WG or implementers.
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
