On Wed, 27 Aug 2014 12:46:41 -0700, Wes Hardaker wrote: >Carsten Strotmann <[email protected]> writes: > >>> Ok then I am an attacker, since you cannot authenticate me, I sign the >>> data myself. This has data integrity. But it is the modified data and >>> not what you expected to receive... >> >> How can you sign DNSSEC data without being in the posession of the >> private signing key(s) all the way to the root? >> >> DNSSEC adds data integrity, and with one or more trust-anchors in the >> resolver the client is able to validate the data, no matter which way >> the data took. > >So, there is some confusion here I think so we need to be clear about a >few things. We're talking about privacy, and in this context >stub-to-resolver entirely. There are two forms of >integrity/authentication going on and they need to be clearly separated >but I keep seeing them being thrown together. > >DNSSEC absolutely helps you ensure that the end data you got is "good" >from the notion of the publisher. > >But it doesn't help you to identify the public key of the resolver >you're using to query for those results. So it doesn't help you ensure >you're encrypting your packets to the right destination. And DNSSEC may >ensure you have the right data, but it doesn't help you determine if you >really did get it in a way that no one else but you, the coffee shop >owner, and the final destination could see. And this is the important >bit: in the context of the discussion, we are only talking about >verifying the public key of the resolver in order to implement privacy; >Clearly DNSSEC has solved authenticating the data itself and that's not >in question. I think most people understand this difference (I hope). > > >But here's the thing that is keeping me awake at nights in this topic: >we keep saying that "un-authenticated encryption is better than no >encryption". And I do generally think this is true. At least you're >only transmitting your data to one potentially bad person (the one >you've done a key negotiation with) rather than letting anyone with 100 >feet view the data. > >But then, stepping back, you have to ask yourself: what's the likely >threat model of everyone in 100 feet trying to attack you? If we really >... > >But what's the solution? How do we authenticate that resolver? PKIX >won't help us, as there is no name. DNSSEC won't help us, as half the >time you're behind a nat so the reverse tree can't be used [ipv6 >actually might help here]. Leap of faith is probably better than >nothing if you frequent that coffee shop. I don't think secure dhcp has >gotten that far, but I'm admittedly out of touch. > >We simply keep moving this chicken/egg problem of secure bootstrapping >from one protocol to the next. It's like one egg that keeps changing >chickens.
I want to take a step back to consider a different case. The complaint here is that it is tough to authenticate some arbitrary resolver handed to you from DHCP because of person-in-the-middle. Yes, that's a hard problem. "Doctor, it hurts when I do this." "Don't *do* that." If you aren't willing to trust a resolver from DHCP, one could use a public DNS resolver, acquire its certificate out-of-band, and check it. I.e., do certificate pinning on the TLS certificate you plan to use for DNS. I'm told there are IP addresses of a public resolver spraypainted on walls in Turkey you could try. (If that or some other provider supported TLS for DNS.) -John _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
