On Aug 27, 2014, at 12:46 PM, Wes Hardaker <[email protected]> wrote:
> But what's the solution? How do we authenticate that resolver? PKIX > won't help us, as there is no name. Say what? That draft clearly says that the resolver can have a PKIX certificate with its IP address as the 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]. Right, but irrelevant, since the stub is assumed not to be a validating stub because so few are. > 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. Secure DHCP is just moving the egg around. The likelihood that you have the coffee shop's DHCP server's credentials are zero. You also forgot other options, such as preshared signing key. That would work fine for enterprises or ISPs with a help desk and a few thousand users. "Paste this into that dialog on your computer" works OK. But PKIX with IP addresses is probably more scalable. > 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. Please look at the draft again; I don't think it is as bad as you are saying. --Paul Hoffman _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
