Re: [dns-privacy] Some additional signalling ideas

[Ilari Liusvaara <[e-mail]>]

On Sun, Mar 31, 2019 at 05:48:21AM -0700, Watson Ladd wrote:
> Dear all,
> Please rip these ideas to shreds:
> 1) An extra bit in a response for "you could have asked over TLS"

Seems vulernable to downgrade attacks. And seemignly leaves obtaining
the authentication data as open problem.

> 2) An extra field when looking up the nameserver for  "you can ask
> that server over TLS"
> 3) An extra field/bit/convention for "this nameserver supports tls"
> (like tls-ns vs ns)

There are only two records that live on parent side of zone cut, namely
NS and DS (then sometimes one sees "glue" A/AAAA records, needed to
break  chicken-and-egg problem if nameservers for zone are inside zone
itself).

NS is AFAICT not signed, and can only contain hostname of the
nameserver. There are some nasty hacks that code the key into this
name, but those suffer from variety of issues (problems with "cloud"
DNS provoders[1], difficulty of rolling keys, etc...).

DS is signed, and has algorithm field. Supposedly unknown algorithms
are ignored, but there are buggy nameservers out there that break if
all DS entries have unknown algorithm. And turns out abusing DS
records also runs into issues with "cloud" DNS provoders.

Adding another RRtype with needed magic properties would take Standards
Action (as expert review requires RRtype not to be magic) and then
updating parent nameservers to be able to deal with the RRtype (since
it can not be generically handled). And trying to add extra fields to
NS or DS is sure to cause horrible borkage.

One could possibly hack around the "cloud" problems by adding yet
another RRtype (that is not magic from DNS data model perspective)
that lives under the nameserver name and contains the final keys
(and adding an optional layer of indirection).

Adding records at child side of cut has its own issues, namely that
retroactive authentication can be annoying to implement, and it is
more difficult to make the thing work without full DNSSEC chain
(glue records, if parent supports that?).


-Ilari