On Aug 20, 2014, at 6:30 AM, Jacob Appelbaum <[email protected]> wrote:
> On 8/19/14, Paul Hoffman <[email protected]> wrote: >> [[ Combined PaulW's and Jacob's responses ]] >> >> On Aug 19, 2014, at 2:01 PM, Paul Wouters <[email protected]> wrote: >> >>> On Tue, 19 Aug 2014, Paul Hoffman wrote: >>> >>>>> I wonder this 'MUST' may be too strong (or I don't fully understand >>>>> the sense of this MUST). Since the upstream recursive resolver may or >>>>> may not support the TLS extension, the DNS forwarder may end up giving >>>>> up the resolution altogether. But depending on the stub clients' >>>>> policy it may be still better to provide encryption between the stub >>>>> and the forwarder. >>>> >>>> Good catch. Proposed replacement to handle the case where the recursive >>>> resolver doesn't do TLS: >>>> >>>> A stub resolver cannot tell whether it is sending queries to a >>>> recursive resolver or to a DNS forwarder. Therefore, a DNS forwarder >>>> that acts as a TLS server for DNS requests MUST also attempt to act as a >>>> TLS >>>> client for queries to its upstream recursive resolvers, but MAY >>>> use the normal DNS protocol on port 53 if an upstream recursive >>>> resolver does set up a TLS session. >>> >>> A resolver at a coffee shop is mostly concerned about protecting the DNS >>> in the public wifi, and might not worry at all about its DSL uplink, >>> especially when it has no real reason to trust its own uplink. So I >>> would just make it very generic: >>> >>> a DNS forwarder that acts as a TLS server for DNS requests SHOULD >>> attempt to use TLS with its upstream resolver(s) to maximize the >>> anonymity of its stub clients. >> >> I'm fine with that as a replacement for my suggestion above. > > I'd switch this to say 'confidentiality' rather than anonymity. > Anonymity is a much stronger claim which I adore but it seems out of > place here. Good catch, yes. >>>> 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. >>> >>> MAY sounds a little odd here. If there is no preconfiguration for >>> authenticating this resolver, I don't think we should advise >>> stubs to refuse to do DNS completely, which is what the MAY is >>> suggesting as a valid option. (this is breaking the "opportunistic >>> security design pattern recommendation advise" :) >>> >>> How about: >>> >>> If a recursive resolver for which an authentication method is >>> available does not respond on port 443 or fails to set up a TLS >>> session, the stub resolver SHOULD NOT use that resolver over >>> unencrypted DNS using port 53. If no authentication method is >>> available for the recusive resolver, the stub resolver SHOULD >>> fallback to using cleartext DNS on port 53. >> >> That seems mixed up. I think the policies we want to list are: >> >> a) Must have authenticated TLS, otherwise don't get any DNS responses >> >> b) Try to do authenticated TLS, but use unauthenticated TLS if possible, >> otherwise don't get any DNS responses >> >> c) Try to do authenticated TLS, but use unauthenticated TLS if possible, but >> allow cleartext on port 53 if TLS cannot be established >> >> Does this seem like the whole list? > > d) Don't do TLS at all, only try cleartext on port 53 (the sad default > state of the internet today) Hrm. That is not really a policy choice for *this draft*, but I see your point. I'll add it. > e) All the other DNS privacy stuff - eg: OpenDNS's encrypted DNS > stuff, djb's other work, etc. I can't list a policy that I can't cleanly describe. The OpenDNS folks still haven't produced a stable description of their protocol that I can find; if they have one, I'm happy to list it. DNScurve doesn't work for stub-to-recursive, I don't believe; only recursive-to-authoritative. >> On Aug 19, 2014, at 1:02 PM, Jacob Appelbaum <[email protected]> wrote: >> >>>>> 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. >>> >>> That is correct and that is exactly what I expect when my network is >>> attacking me. Rather than leaking that I'm being visited an ad name >>> that implies I've visited a gay dating site, I want it to fail closed. >>> If I declare it as secure, I want it to remain secure - where the >>> security here is all about *confidentiality* and DNSSEC does the rest >>> with regard to integrity, etc. >> >> I think that would policy (a) listed above. Does that work for you? > > Yes. It is perfectly fine. If it was the default policy when > configuring a TLS aware resolver unless configured to be *less secure* > explicitly, certainly so. The document is not going to list what a default policy should be. >>>>> 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. >>> >>> If the TLS connection fails to complete (authenicated or not), it >>> should be as simple as returning something like E_CENSORSHIP_DETECTED. >> >> It is reasonable for the policy to suggest that a later API might be able to >> detect which level of protection, if any, the user has gotten. > > I like the idea of a notice but I prefer the idea of explicitly > ensuring that one has configured a privacy DNS resolver - thus - it > seems the API needs to consider this from the start. If you want to work on an API, that's great. APIs for security have a long history of bringing down protocols in the IETF, I don't want the API to hold up the protocol. If you get started on it before this document is finished, I'm happy to point to your work-in-progress. >>> An error like "Unable to connect securely to resolver, please contact >>> your ISP" would be fine. >> >> And you might want to only use applications that use that later API. >> >>> Most OSes don't do anything remotely helpful when DNS fails. It might >>> be nice if that failure mode was privacy preserving... >> >> It might be, yes. >> >>>>> 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. >>> >>> If my resolver allows upgrading to a secure method of communication, >>> I'd like to know. Furthermore, I'd like to automatically upgrade to >>> that secure communications path if it was available. An OS could probe >>> for a specific record type - similar to say, version.txt. >>> >>> e.g.: nslookup -q=txt -class=CHAOS query.privacy.bind. >>> >>> It could even learn the likely fingerprint of the server ala DANE, for >>> example. >> >> Once we have privacy for all types of stub resolvers, it could certainly be >> useful for a few people who have security-aware validating stub resolvers to >> have that information. It is an easy follow-on for those who care about it. >> > > I think a key thing is that we need a way to discover that an already > configured stub resolver supports this kind of confidentiality. When > the stub software updates, the resolver that is already configured > could be upgraded to use the privacy preserving path, for example. That would take an API. I really don't want to force that into this document, but as I said above, if you or someone wants to tackle the API question, I'm happy to point to it. --Paul Hoffman _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
