> On Mar 15, 2019, at 2:36 PM, Ted Hardie <ted.i...@gmail.com> wrote: > > All of the work on encrypted DNS presumes that there is one or more parties > who wishes to observe the flow of traffic to DNS resolvers for the purposes > of surveillance. The conclusion of the IETF after IETF 88 was that there was > a class of that, pervasive public surveillance, that was so damaging to the > trust of the users in the Internet that it amounted to an attack on the value > of the Internet as a whole. The plenary where that was discussed is online > here: IETF 88 Technical Plenary: Hardening The Internet - YouTube . In a path > with multiple links, in other words, we have a condition where we believe > there is likely to be an attacker on one or more of those links that would > like to see this data and to use it for purposes not approved by the user or > the operator of the service to which the user is directing her flows (or any > of the network operators through which the flow passes). > > The response to that has been first to encrypt the flows which carry the user > data. That's not an effort championed not only by the IETF or the IAB; see > the US Government's HTTPS Only standard for one example of the many other > efforts going on to make that the case. In addition to that primary effort, > there have been efforts to reduce the amount of metadata about the flows. > Some of that has been in updating transport protocols (e.g. QUIC, TCPINC) to > reduce their disclosure of state. Some of it has been in reducing the data > revealed by the handshake (e.g. the updates in TLS 1.3 and eSNI). And some > of it has been to reduce the data disclosed across those links by the use of > the DNS. That's the point of DNS over TLS and DNS over DTLS; it's also the > point of DNS over HTTPS: to protect the data in those flows from a known, > pervasive attacker. > > You would like your use of similar surveillance techniques to be > differentiated from their use by that set of attackers. The IETF cannot do > that on moral grounds, much as we might like you and appreciate your desire > to protect your network and your children. We need technical mechanisms. If > you review the discussion to date, you'll see a number of such mechanisms > proposed. They fall into two broad classes: trusting the local network > infrastructure and trusting the local configuration. >
Once you make all traffic look the same, expect it to be treated the same as possibly malicious by network operators. Do you know why software has options like avoid-v4-udp-ports as a config directive? Expect that to happen regardless of where you move the transport to. I’m writing this from my own machine that I own, purchased and paid for with my own $$. If you’re writing from a corporate owned machine, or reading on a corporate owned machine they likely have their own rules for them. I believe in the open internet, but I also don’t believe in the absolutes people see this in. You aren’t entitled to all communication in the world. The IETF can try to carve out a moral high ground that you are referring to. It may be sound footing, but if you’re in a place where a DNS query for example.com is problematic, one of the solutions is to NOT look up example.com. It may not be “right” in your mind, but it is a way to prevent being jailed or otherwise which we may both morally agree is the wrong outcome but those other locations that made example.com bad may not care and no writing to/in an IETF WG will change that a single bit. That change lives outside the IETF WG process. - Jared _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
