Re: [dns-privacy] Moving things along...
On Wed, Feb 18, 2015 at 04:50:49PM -0500, Warren Kumari war...@kumari.net wrote a message of 78 lines which said: Sorry, I should have been more clear - draft-hoffman-dprive-dns-tls-* has been combined with the Verisign document. No, _I_m sorry, I didn't read draft-hzhwm-dprive-start-tls-for-dns-01 yet. Doing it now. ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Moving things along...
Hi Warren, On , Warren Kumari wrote: On Wed, Feb 18, 2015 at 3:26 PM, Hosnieh Rafiee i...@rozanak.com wrote: Does it mean that you want to only go with solution to change DNS protocol? You don't want to put any other solution in agenda which doesn't change much the DNS protocol such as cga-tsige. The might be more examples. The CGA-TSIG document itself seems to have been shopped around a large amount, starting in 2012 -- I see it being pushed in IntArea, SAAG, DANE, DNSOP, DNSEXT and DPRIVE. It has been discussed in DPRIVE, but I did not get the sense that the WG had interest in pursuing it. There were some questions / confusion about what exactly it provides / how it works. You did request agenda time in Dallas - we only requested a 90 minute slot, and so can only give you 10 minutes to present and answer questions - if the WG shows support after that we can discuss adopting this as well W I am going to do another revision before cut off date. Please allocate this 10 mins to this draft (hopefully this is enough). I will use this time only to cover questions rather than explaining the detail idea. Thank you, Best, Hosnieh ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] I-D Action: draft-ietf-dprive-problem-statement-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS PRIVate Exchange Working Group of the IETF. Title : DNS privacy considerations Author : Stephane Bortzmeyer Filename: draft-ietf-dprive-problem-statement-02.txt Pages : 15 Date: 2015-02-19 Abstract: This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions. Discussions of the document should take place on the DPRIVE working group mailing list [dprive]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dprive-problem-statement/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dprive-problem-statement-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-problem-statement-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] A different way to look at the problem
DNS privacy requires us to make two changes to the DNS protocol. 1) The resolver is acknowledged as being a trusted service 2) Some form of crypto is added between the transport and application layer in the client-resolver protocol. So far we seem to have focused on the second issue. But that is the easy one. There is really nothing at all special or interesting in the way TLS or DTLS or my proposal add crypto to packets. That part of the spec can be implemented in an afternoon. The hard part is the consequences of the first issue. Whether or not we want to trust the resolver to give us the right data (integrity), privacy demands that we trust the resolver not to disclose the data (confidentiality). Question: Is anyone proposing that we can achieve DNS privacy while maintaining the current practice of the client defaulting to the DNS server advertised in DHCP? I don't think that is the case. But I thought best to check. Once we decide that the client is going to have a persistent relationship with a specific DNS service we face the problem of how to establish and secure that relationship. The main difference between my proposal and the VeriSign/USC proposal is how we go about achieving that. We are both proposing to use TLS as a basis for this interaction. The difference being that I am proposing to use the TLS infrastructure and PKI path math once to establish a long term credential and the VeriSign proposal is to use TLS on each client-resolver interaction. Now before making a choice between one approach or the other, I strongly recommend people look at what is being proposed in ACME. While this looks like a completely different problem (PKI credential provisioning versus service discovery), it actually isn't. In both cases we have a hard problem and an easy problem. The easy part being the bit that is different and the hard part being how to establish and maintain the binding between the client and a trusted service. I think that if we could factor that part out and make it a reusable component, we would be doing the IETF a big favor. The reason I don't want to use TLS for this is that neither TLS not PKIX is a good tool for this particular job. PKIX ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] Review of dprive-problem-statement-01
On Feb 19, 2015, at 12:04 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote: Now published but only in french. Interesting Internet governance issue :-) Can I add a reference to a document in non-english? Yes. And you should. (And I say this as someone who is unable to read French.) There is precedent for it: RFC 4357 has normative references to documents only in Russian. --Paul Hoffman ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] A different way to look at the problem
Question: Is anyone proposing that we can achieve DNS privacy while maintaining the current practice of the client defaulting to the DNS server advertised in DHCP? Yes, cga-tsig *might* be an option but for DHCP security, it is dependent to SAVI-DHCP or any monitoring mechanism in the network. You might want to take a look on section http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-11#section-2.1 or wait for revision version for better text. Best, Hosnieh P.S. please don't comment on section 2.2.4, that section need a major revision as it is old. Thanks! ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] A different way to look at the problem
On Thu, Feb 19, 2015 at 1:21 PM, Ted Hardie ted.i...@gmail.com wrote: Howdy, On Thu, Feb 19, 2015 at 7:20 AM, Phillip Hallam-Baker ph...@hallambaker.com wrote: DNS privacy requires us to make two changes to the DNS protocol. I'm a little confused as to why this isn't on DPRIVE, but okay. So was I. I typed in DNS-privacy... it ended up in DISCUSS. :-( So lets continue the rest in DPRIV... So let's agree to the framing a bit. There are two exchanges in the current system: resolver to authoritative and client to resolver. It's important that the resolver to authoritative exchange not leak more information to the authoritative server than is necessary (e,g, passing along the client's IP at single IP granularity). Actually that part of the protocol is currently out of scope. We are looking at the client-resolver link first. If/when we get to that part of the protocol we should probably formalize some sort of mechanism to allow the resolver to tell the authoritative what the BGP ASN number of the IP address is precisely to prevent finer granularity leaking while allowing CDNs to still work efficiently. It is useful if the system allows for the traffic between the two be encrypted so that eavesdroppers cannot read them (for large installations with lots of clients behind them, the leakage in that eavesdropping is diffused by the difficulty of associating it with specific clients, so it may not be used everywhere, but it should be possible). I think the work so far has presumed that this exchange is, however, the less urgent one to protect, and that client to resolver is more urgent. Yes, that is indeed where we are. While I would never design a client-resolver loop without also writing a spec for a resolver-authoritative to make sure that both can be handled in a consistent and clean fashion, it is not necessary for us to be discussing both in IETF at the same time. As you note, protecting the exchange between client and resolver so that it is confidential is one critical aspect; encrypting the exchange does that. Having the client able to perform integrity checking (presumably using DNSSEC) allows it to verify that the resolvers is providing the data entered by the zone maintainer. Whose authentication is relevant depends on whether we are doing a layer 5 DNS lookup (A or ) record or a layer 6 DNS lookup (everything else, including TLSA records). Authentication of A and 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. An A or 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. There are certainly good reasons for wanting to provide DNSSEC records for A/ to the resolver but there isn't a good case for the client checking. [Again, TLSA and other security policy records are a totally different matter.] Allowing the client to rewrite A and records allows a DPRIV resolver to provide DNS64 service so an IPv6 only client can function without any IPv4 support at all. Whenever it tries to access an IPv4 only resource, the resolver gives it an address at NAT64 gateway. But that is a digression. The critical issue here has often been latency--clients have been reluctant to do that in real time, as the resulting increase in latency was bad for operations. There may be ways to improve that--by having the resolver perform those functions but also consistently provide the client with the data used to verify, so that it can cross-check at some configured rate (trust, but verify). In my current proposal, all the crypto in the client-resolver interaction loop is done using symmetric key cryptography and a Kerberos ticket like scheme. The performance impact is negligible. Given the current state of the CFRG discussion on ECC curves, the use of Curve25519 in place of the symmetric crypto is certainly worth considering but it does not change the design very much. The other issue you raise--can you trust the resolver not to forward the data to some third party? That depends on your definition of trust. I define trust as being able to accurately estimate the probability of default and determine that it is within acceptable limits. 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. boils down to a relationship question for which there are a couple
