On Aug 29, 2014, at 5:30 AM, Wes Hardaker <[email protected]> wrote:
> Paul Hoffman <[email protected]> writes: > >> 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. > > So we're going to issue a gazillion PKIX certs for 10.0.0.1? Sure, why not? If you have an internal CA that is trusted by your users, there are no different issues for it writing certs for a private address that might overlap with systems in different address spaces than there is for it writing certs for private names that might overlap with systems in different namespaces. >> The likelihood that you have the coffee shop's DHCP server's >> credentials are zero. > > I think I was implying that so we agree :-) Good. >> 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. > > Well, I thought about the coffee shop sign (here's our WPA password > along with our resolver's magic verification string). Sure, that would work. But more importantly, if what we are trying for is opportunistic security, the MITM would have to be in the coffee shop, unless the coffee shop's DHCP server says that the recursive resolver is on the public internet and that resolver doesn't have a valid cert. --Paul Hoffman _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
