On 8/19/14, Paul Wouters <[email protected]> wrote: > On Tue, 19 Aug 2014, Jacob Appelbaum wrote: > >>> Sure, let's be explicit. Proposed addition to the policy section: >>> >>> If a recursive resolver does not respond on port 443 or set up a TLS >>> session, the stub resolver MAY use the normal DNS protocol on port 53. >>> >> >> I'm not a fan of making it possible for an attacker to downgrade with >> a single (non-cryptographically protected) TCP RST packet. > > So you would want DTLS? >
It depends; perhaps? An on-path attacker can mess with TCP and UDP by dropping. There isn't much to be done there. An off-path attacker (eg: QUANTUMINSERT) is a Machine-On-The-Side and in that case, TCP still falls over. DTLS may do better, I'm not sure. > The ALPN would also mark you censorship. In fact, just attempting to get > encrypted DNS in whatever way would mark you as such. If you tunnel all > of this over 443, they will just have to block all of 443. I'm not clear that this is true - I think encrypting all DNS provides a kind of herd immunity: this is the way the network works and major DNS providers will support a secure option. If only those that need it, ask for it, then yes, it is a distingushing feature that is likely a problem. And yes, they'd have to block all of 443. This doesn't happen as often as we'd think, I suspect. Also, if they have a single switch - they kill it for *everyone* and not only for selected folks by keyword. This creates a lot of social pressure. In my experience with Tor being blocked in Iran - it is much easier to block Tor than it is to block Google. This isn't just technical. It is also about deployment - the one everyone uses is normal and not as acceptable to block all of the time. > > An attacker on the local network could just forge the DHCP server. A lot of people manually set their DNS servers in censorship prone countries. I've heard that Google selected 8.8.8.8 for cultural reasons in addition to being a nice short number. > But > an attacker on-path on the internet could indeed send an RST packet. An attacker can inject if they've seen the handshake - they don't have to be on-path to tear it down. > However, most likely an attacker that can inject a packet can also > filter one out, so how common is the case of a non-local RST attacker? > I think it is pretty real: https://en.wikipedia.org/wiki/QUANTUMINSERT#QUANTUM_attacks To compare - Iran has edge routers that are often hostile (on-path) and the NSA/GCHQ have that at defense networks, as well as off-path injection all around the world. We have to deal with both kinds of attackers, I think. Jerks. :( > If you are connecting to a remote DNS server for TLS, I would assume > you also have an out-of-band key (like a TLSA record) to authenticate > the resolver. You would detect this failure and know you are on a > hostile network. > Yes, that sounds about right. >> If I >> configure a resolver and declare it to be secure (and use it as such), >> why not fail closed? Why not detect that as an attack or as outright >> network censorship? > > I don't think the draft says anything about how to handle failure? It should. We should actually handle attacks in the wild and not treat them as rare flowers that are never expected to be found. > >> This seems to fail if there is an active attacker that blocks TLS >> traffic - is there a way for the resolver to somehow learn in-band on >> port 53 that this attack is happening? > > If you would publish a TLSA record, then yes. eg: > > _443._tcp.8.8.8.8-in-addr.arpa IN TLSA <google-dns-pubkey> I think that is a good start but I was thinking about service discovery - that is I have to know to look for that record. > > Seeing the responses so far, I think the document needs to be much > clearer with respects to "last mile" versus "remote DNS server" > encryption. > They're essentially the same problem when you use OpenDNS, Google's public DNS, Sonic.net's awesome resolvers, and so on. All the best, Jacob _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
