When the IETF documents something, that is unavoidably an endorsement. We should be cautious about what we endorse.
To some degree, but when we imagine that not documenting something that already exists will make people stop doing it, we just confirm the impression that we and our standards are out of touch with the real world.
In this case, the risks may be less obvious, and we should work to make them more obvious. For example, we could decide to add a mandatory client IP field. This would help to emphasize that the data is in fact highly sensitive, and must be treated with the same level of caution as other PII logs.
We could, and all the passive DNS operators who have already implemented this decade old draft will roll their eyes and continue doing what they have been doing. That is an excellent example of what *not* to do.
If you're running 8.8.8.8 your logs have a whole lot of PII, but if you're running resolvers in front of industrial networks and using PDNS to look for malfunctioning or compromised IoT boxes, there's no PII at all. Everything we build is at least dual use, and we are not very good at guessing how people will use them.
As it stands, I think this format is something of a privacy footgun. It looks reasonably deidentified, but in the DPRIVE threat model (see e.g. RFC 7626) it is highly reidentifiable.
I completely agree that we need to document the security and privacy issues and suggest ways both to understand what they are, and how to mitigate them. But if we imagine that we are smarter than the people who use our specs, well, we aren't.
Regards, John Levine, [email protected], Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
