Bob, At 2016-07-19 11:28:12 -0400 Bob Harold <[email protected]> wrote:
> On Tue, Jul 19, 2016 at 11:18 AM, Stephane Bortzmeyer <[email protected]> > wrote: > > > On Tue, Jul 19, 2016 at 11:11:18AM -0400, > > Bob Harold <[email protected]> wrote > > a message of 130 lines which said: > > > > > I would think that "Key in DNS, authenticated by DNSSEC" would be > > > the obvious choice. > > > > It is mentioned, section 2.2. > > > > For the -00 version, I did not try to order ("obvious" or "best") the > > choices. Feedback welcomed. > > > > I was confused by the "bootstrap" issue, or why talk to port 953. I was > assuming normal unencrypted DNSSEC to get the key, and then encrypt the > query that I wanted to protect. I can see why some would want to try to > make private getting the key, if possible, but it really complicates > things, so I am not sure it is worth it. (Just my opinion, of course.) As Stephane says this is better than nothing, but it would be nice to design a protocol that doesn't leak any information. Unfortunately the bootstrapping issue is a tricky one. A few other random thoughts... While the draft mentions that resolvers are configured by IP address and authoritative servers by name, actually when a resolver is talking to an authoritative server it is actually using an IP address. That implies a couple of possible solutions: 1. Using reverse DNS to get a key for the server. There may be a slight boostrapping problem here too, but since there are only 5 RIR that manage the reverse DNS some sort of hard-coded or semi-hard-coded setup might be possible. Unfortunately the operators for the space are often different from the operators of the DNS, so this is often not a reasonable solution administratively. 2. CGA-style keys. In CGA, the IPv6 address encodes the public key in the lower 64-bits of the address. So we can use the IPv6 address as the public key of the servers. This only works for IPv6, doesn't have (much) cryptographic agility, and totally ignores any layering so much that it is a stretch to even call it a layering violation. :) ---- Another way to resolve the bootstrapping problem may be to create a record which lives in the parent, like a DS record. It could be considered as a crytographic-glue. Like an A or AAAA record, it would only be necessary for in-bailiwick lookups. Like a DS record, there are potential coordination issues between parent and child. Also like DS, presumably it could be signed by the parent and treated like a normal (non-delegation) record. Also like the DS record, we use the pre-existing trusted channel between the child and parent to get cryptographic information from the child to the parent for use by resolvers. Cheers, -- Shane
pgp4AgjBLBXei.pgp
Description: OpenPGP digital signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
