Re: [dns-privacy] Issues with encoding keys in nameserver DNS names

[Daniel Kahn Gillmor <[e-mail]>]

On Fri 2018-12-14 19:12:41 +0100, A. Schulze wrote:
> Am 11.12.18 um 06:38 schrieb Mukund Sivaraman:
>> There was some discussion in last night's meeting about encoding keys in
>> the DNS name of a nameserver, similar to DNSCurve. There are at least
>> some issues with it:
>> 1...4
>
> 5. Encoding a key as DNS name of a nameserver makes key rotation harder.
>    Not impossible, but really much harder.

i agree that it makes it harder, but i'm not convinced that it is *much*
harder.

Pretty much all TLS stacks today will let you associate different
keys/certificates with different server names, so as long as resolvers
send SNI to their resolvers (should we MUST that?) then it works like
this:

As an authoritative server operator, for rotation, you'd:

 * create a new key
 * create a certificate for it (or just use TLS raw public key)
 * tell the TLS frontend to use both certificates/names
 * add a new NS record
 * remove the old NS record
 * once its TTL has expired, remove the old certificate/name

if you're serving many zones from a single authoritative server, it
would require you to update the NS records for all zones, though -- that
is maybe more of a challenge (especially if they all use different
registrars and you're trying to update glue) than the above process,
which is fairly well-defined.

But maybe it's worth reviewing what we're hoping to gain from the
keys-in-names approach too:

 a) indication that private queries are expected to work to this
    particular resolver

 b) cryptographic identity material

If we care about both (a) and (b), then keys-in-names makes sense
(though it has the friction for rotation that you describe).

But what if we cared only about (a) ?  could we signal with a
special/magic terminal label just that private queries are expected to
work, without embedding a key there?

then we could rely on "the usual mechanisms" (the CA system, DANE) to
address the authenticity problem, rather than an embedded key.

For example, maybe the terminal label of your NS record could be
"yes-it-does-dot" :)

    @ 1D IN NS yes-it-does-dot.a.ns.example.net.
    @ 1D IN NS yes-it-does-dot.b.ns.example.net.

what do folks think about the tradeoffs there?

      --dkg