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?
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.
An attacker on the local network could just forge the DHCP server. But
an attacker on-path on the internet could indeed send an RST packet.
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?
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.
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?
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>
Seeing the responses so far, I think the document needs to be much
clearer with respects to "last mile" versus "remote DNS server"
encryption.
Paul
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
