Subject: [dns-privacy] Some additional signalling ideas

From: Watson Ladd <[email-masked]>
Date: Sun, 31 Mar 2019 05:48:21 -0700

Dear all,
Please rip these ideas to shreds:
1) An extra bit in a response for "you could have asked over TLS"
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)

Sincerely,
Watson Lad

---

From: Ralf Weber <[email-masked]>
Date: Sun, 31 Mar 2019 16:15:46 +0200

Moin!

> On 31. Mar 2019, at 14:48, Watson Ladd <[email-masked]> wrote:
> 
> Dear all,
I assume with this sentence you mean that the following ideas are bad ideas. Is this correct? If so why not say so, as there are a lot of people in here including myself who are not native English speakers. 

> 3) An extra field/bit/convention for "this nameserver supports tls"
Can you please explain your opinion on these rather then stating that they are bad (or good). 

So long
Ralf

Sent from my iPhone

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 31 Mar 2019 17:22:02 +0300

> 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.

> 3) An extra field/bit/convention for "this nameserver supports tls"

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

---

From: Watson Ladd <[email-masked]>
Date: Sun, 31 Mar 2019 07:31:29 -0700

> I assume with this sentence you mean that the following ideas are bad ideas. Is this correct? If so why not say so, as there are a lot of people in here including myself who are not native English…

I meant I think they are good and they probably aren't so why? I don't
know that much about DNS.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 31 Mar 2019 16:38:46 -0400 (EDT)

> 1) An extra bit in a response for "you could have asked over TLS"

Too late, you already lost your privacy.

> 2) An extra field when looking up the nameserver for  "you can ask

Where would this field be? Not a DNS option because that would take 10+
years to roll out. also how would this option be secured?

> 3) An extra field/bit/convention for "this nameserver supports tls"

Same as above.

There was a reason I somewhat joked about DNSKEY flags. It is one of the
view signaling methods we have that is secure and is about publishing
something at the parent on behave of the child. But I don't think this
is a real solution either. It would be a very bad signaling hack.

The trick will be to have nameservers that are not within bailiwick
of the zone. Then if the parent's transport security was good, you get
nameservers which you can query for TLSA or tls-dnssec-chain to get its
TLS/HTTPS key. Then query it for the target domain zone. And at that
point you do not need a flag anywhere else either. And knowing you are
querying ns.bighoster.com shouldn't reveal which domain you are looking
up specifically.

All of this assumes query minimalization too (obviously, if you do not,
then you leak the target domain all over the place)

It also leaves the domains with bailiwick without protection, but those
target domains should only be hosting NS/A/AAAA of nameservers so the
privacy loss is minimal.

Paul

---

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 1 Apr 2019 08:19:21 +0200

All,

> 2) An extra field when looking up the nameserver for  "you can ask that
> server over TLS"

[AM] Another "probably bad idea", as mentioned in the WG session... 

4) And EDNS0-option "Encryption available" sent from server to client, eventually including flags for which encrypted protocol is available?

I have some experience in creating drafts for "funny" EDNS0-options (RFC7830), so I'd volunteer :-P

Best,
Alex