In message <[email protected]>, Wes Hardaker writes: > 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).
Actually DNSSEC could give you the key of the resolver securely provided it has a public address. Publish a KEY record signed in the DNS under in-addr.arpa or ip6.arpa. If need to we define flag bits to say it is for this purpose. For private addresses you need to have a trust anchor for the private part of the reverse tree or use leap of faith. This also works for any authoritative server. Alternatively we could allocate a new type to hold the key material. You can't hide that you are talking to a resolver so there is no need to encrypt the lookups for the KEY, DNSKEY, DS lookups required to validate the KEY. > 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 > are worried about protecting people at starbucks, what's the likelyhood > of 2 people in starbucks trying to sniff your private dns lookups at the > same time? Probably super-duper low. So, are we really protecting you > at all if the one bad person in the coffee shop is able to convince you > it's the local resolver? IE, if we blindly assume that whatever key we > get is ok then we're buying ourselves very minimal protection against > the few opponents within spitting distance of a wireless box. Likely > there will be just one, and it'll likely succeed in defeating your > encryption. > > Now, in larger venues where are there are potentially lots and lots of > people that are targeting an environment for sniffing, say at an IETF > convention where we're very good at overwhelming infrastructure, then > the likelyhood of having multiple malicious eves goes way up and maybe > we've achieved a bit of protection by transmitting our dns request data > to just one advocacy instead of them all. > > > 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. > > -- > Wes Hardaker > Parsons > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected] _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
