Re: [dns-privacy] [[e-mail]: I-D Action: draft-bortzmeyer-dprive-step-2-00.txt]

[Shane Kerr <[e-mail]>]

Bob,

At 2016-07-19 11:28:12 -0400
Bob Harold <[e-mail]> wrote:

> On Tue, Jul 19, 2016 at 11:18 AM, Stephane Bortzmeyer <[e-mail]>
> wrote:
> 
> > On Tue, Jul 19, 2016 at 11:11:18AM -0400,
> >  Bob Harold <[e-mail]> 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