On Aug 19, 2014, at 11:51 AM, Jacob Appelbaum <[email protected]> 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. If I
> configure a resolver and declare it to be secure (and use it as such),
> why not fail closed?

Because then hosts that use stub resolvers will not be able to use the DNS at 
all.

> Why not detect that as an attack or as outright
> network censorship?

We could add such detection, but only if the value outweighs the complexity and 
possible failure modes.

> 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?

Probably, but you still haven't said what value there is in knowing that. A 
stub resolver has no log and no way of alerting anyone that it discovered 
something important.

Let me know if I'm missing something obvious.

--Paul Hoffman
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to