On Mon, Feb 23, 2015 at 12:42 PM, Ted Hardie <[email protected]> wrote:
> Howdy, > > Sorry for the delay in replying. Additional comments etc. below. > >> >> Whose authentication is relevant depends on whether we are doing a layer >> 5 DNS lookup (A or AAAA) record or a layer 6 DNS lookup (everything else, >> including TLSA records). >> >> Authentication of A and AAAA records is certainly desirable in the now >> obsolete approach of taking the nearest DNS service because you are taking >> the data from an untrustworthy source. But once we direct our queries to a >> service we consider to be trustworthy, it is neither necessary nor >> desirable. It is actually better to let the resolver do the authentication. >> >> > I don't think I agree with this conclusion. The theory of DNSSEC has > always been that if you can validate the cryptographic bits, that the > answer matches what the zone maintainer put in the zone, and so you don't > care any more where you got the data. I think that remain pretty powerful, > especially for for the cases after bootstrapping. > This is actually a bit of a red herring as the only changes being considered to the protocol that affect DNSSEC is that DPRIV makes it possible to assume 100% reliability in delivery of the DNSSEC data rather than the 97% reliability in delivery seen with the legacy protocol. Anyone aborting connections on DNSSEC validation in the client today is going to find people stop using their product very quickly. Its like giving someone a shotgun for their 5th birthday secure in the knowledge that they don't have any ammo. DPRIV isn't changing the fact that the gun is pointed at the foot but it is adding ammunition. Unfortunately, the 'theory of DNSSEC' has never explained what a client is meant to do if the process fails. The rule of the game here is that someone has to write a single, deterministic algorithm that exhibits the desired behavior in every circumstance. My experience in DKIM was that when most people played the game they would have two algorithms,, one they proposed for the problem of stopping spam and the other for ensuring connectivity. Deciding what to do if you get a TLSA record with a bad signature, or a missing TLSA record is straightforward: abort the connection because you have a clear security policy failure. Aborting the connection for A or AAAA records at the client looks to me like introducing a DoS channel. It is certainly going to hit a lot of unreliability due to DNSSEC admin goofs like the ones we have seen on the IETF's own pages. > An A or AAAA record is only a binding of a DNS name to an IP address. >> Absent a fully deployed and 100% trustworthy BGP infrastructure, that does >> not provide a secure binding to the endpoint. >> > > So, while I agree that you could construct a topology such that you don't > care where you got to, provided it can prove its the service you want, I > don't think that's the problem we're trying to tackle in this working group > (NDN and friends seem closer). I think we are concerned with the privacy > of uses of the known-item search that is the DNS. > Establishing an encryption channel requires us to establish a shared symmetric key. So we get client-resolver authentication for ~20 bytes of additional overhead. We should make use of that for the following reasons: 1) Protect a DNSSEC aware client against a DNS spoofing attack on the client for the 99% of DNS domains that don't have DNSSEC 2) Provide the client with a cheap mechanism for validation before performing the expensive DNSSEC validation 3) Protect non DNSSEC aware clients. 4) Enable the 'trust at the resolver' model for applications where that is preferred. None of this stops folk who are ready to go ahead with the client DNSSEC validation approach from doing that. All I am saying is that is one model and not the model that I expect to be common for a very long time to come. I engineered Private-DNS to reduce the cost of client-side DNSSEC effectively to zero. We are agreed that should be an option DPRIV makes possible. What I am saying is that it is an option that might not actually meet the real security needs so I am not going to design a proposal that only works that way. What is key here is being able to chose your own trust provider. And there >> are tradeoffs. You can't get privacy in this particular instance by >> deciding to little red hen it and do it yourself. That is like trying to >> hide a tree in the desert. You need a large portal like Comodo or Google >> with a few million customers to be able to hide. >> > > So, I think on this part we're using slightly different terms but agree > on the substance. If you contact the authoritative name servers directly, > the traffic to those servers is traceable even if the question asked is > not. If the authoritative servers themselves serve many different zones, > there may be some difficulty working out what's going on (e.g. > username.microblog.example style services), but generally the traffic to > the authoritative DNS server is revelatory enough. > > Confidential traffic to a large aggregator of queries gives you a better > shot at hindering attempts to correlate the queries in to the eventual > traffic out. > Exactly, if people are concerned about privacy protection they probably want to hook their browser/device up to some large throughput aggregation portal. But that is not the only reason I would expect people to use A DNS protocol transport that offers confidentiality and integrity enhancements. I think the likes of a GM or a GE will run their own DPRIV servers to protect their internal traffic and then do something 'clever' and bound by a lot of confidentiality agreements to conceal their external traffic to the authoritative servers. >> The short term deployment driver for this protocol is likely to be for >> remote workers (like myself) wanting to access some corporate resources >> from BYOD (personally owned) machines. >> >> So I want there to be a process for binding to a DNS service that allows >> the user to authenticate their device that does not force an every-time >> authentication and also we need some mechanism that allows a DPRIV resolver >> to say 'I have special data for example.com' in trustworthy fashion. >> >> > I'm not sure I understand this bit. Are you saying that a query from a > client would trigger this disclosure via information in additional data? > Or that it would be discoverable via something like an SRV record? or via > a different, non-DNS protocol? > Today a lot of enterprises have split horizon DNS. It is a hack but a necessary one. The fact that I put orac.hallambaker.com on my Internal network does not mean that I want the existence of that machine to be visible to people outside my family. So lets say I buy a new machine for work and for personal use. I want to be able to access the following sites: A) developer.corporate-internal.com B) portal.corporate-internal.com C) www.trainspotters.net D) www.golf.net E) pornography.com Where A and B are sites my employer provides that are only visible to employees. There is no reason for non-employees to know they exist so their DNS records are behind split horizon DNS. As an employee I want to be able to get access to the corporate site to do my job but I don't want my employer to see any non-work related activity that might be embarrassing like the golf site. So when I configure my client I would begin by picking my DNS provider 'Comodo.com' which would return some sort of JSON structure describing its services. Then I would add my employer DNS provider employer.com which would return a JSON structure saying that it is 'better' for corporate-internal.com. This would of course be a one time config operation, set and forget. Unless of course I changed employer in which case I would change my settings. > Again this is the sort of area where we can leverage DNSSEC probably. >> >> >> >>> In general, we may want to develop code that allows us to use multiple >>> DNS resolvers, some configured and some provided. Not only would that >>> raise the costs for attackers attempting to develop client profiles, it >>> gives you a secondary method for checking accuracy when DNSSEC isn't >>> available by using a voting-algorithm style anomaly detection (the large >>> caveat here being the knock-on effect on CDN operations, which may well be >>> returning different results to different resolvers if they have no other >>> client data). >>> >> >> Actually for the specific purpose of preventing government censorship >> attacks, DNSSEC does not actually help at all because all DNSSEC can do for >> you is to tell you that there is a hole. If you are trying to access >> Facebook from a censorship state you already know that. What you want to >> know is how to get to Facebook. >> >> > Again, I'm not sure that this group can solve that problem; we are trying > to make sure that the user can ask where Facebook is on the network without > exposing that question to common view and without losing the ability to > confirm that the answer was what Facebook intended. Past that point, we > move out of DPRIVE territory. > The problem comes when the site is russian-business-network.com and the user definitely does not want to go there and get their machine infected. Like it or not, the mere fact that someone has bought a domain name does not mean that I want my machines to be able to connect to them. Every security problem has a simple solution if you decide that it is the only problem you are interested in solving.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
