Subject: [dns-privacy] Comments on draft-lmo-dprive-phase2-requirements-00.txt

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Oct 2019 16:01:09 -0700

Document: draft-lmo-dprive-phase2-requirements-00.txt

After reviewing this draft, it is not clear to me what architectural
model people have in mind. At a high level, say that I attempt to
dereference example.com and I have a cached NS record for .com. So, I
query example.com and get back:

- An NS record for the for the authoritative host, say
  ns.service.example.
- An A record for ns.service.example in the additional
  section.

Given this information, I then connect to ns.service.example
given this IP and query for example.com. So what happens when
we introduce TLS into the equation? In particular:

1. How do I know that the server handles TLS?
2. What identity ought the server to have and how do I verify it?

Now, we already have a worked example of a similar, though not
totally analogous situation in the Web case, so it might be
worth working through it. For instance, what happens when I
want to search for some term "example" at a search engine.
I connect to the engine, give it the term, and then it
gives me some possibilities, each of which is associated
with a link. I click on one, etc. In this scenario, the
answers to these questions are:

1. Primarily, the referring server tells me by using an https:
   URI rather than an http: one. If not, there is a way for the
   origin to redirect me to https:. It also is able to tell me
   that this origin should always use HTTPS using HSTS.

2. The server's identity is the domain name in the URL, and it's
   verified by having a WebPKI certificate with that domain name.

Note that there's basically no context in which the Web client
does any opportunistic probing as suggested by S 4.2. The client
is either trying to dereference something that is HTTPS or it is
not.

If we try to transplant this into the DNS model, it would seem we
want something like:

- There's something in the additional data section (i.e., the
  reference) that tells the recursive resolver that this nameserver
  supports DoT. [Analogous to the https: scheme]

- There's a way for a server to tell clients that it supports DoQ and
  commit to it for some future period [Analagous to HSTS.]

- The domain name in the NS record is used to authenticate the client
  via TLS, tied back to some external authentication scheme (WebPKI or
  DANE) [Analogous to the host portion of the HTTPS URI].

I think this helps answer some of the questions asked by this draft.
Specifically:

- In S 4.3, the answer ought to be "by identified nameserver". The
  other alternatives seem much more confusing to reason about.
  IP address specifically is a problem because it courts downgrade
  attacks.

- In S 4.3, I don't think talking about privacy over availability
  is that helpful. The semantic you want is that the server
  is committing to supply DoT for some period of time and then
  clients can decide if they want DoT. I think it's unwise to
  ever allow fallback from DoT to Do53 because that makes
  downgrade easy. I would expect that recursive resolvers
  will by and large operate in environments where DoT filtering
  is not an issue.

- S 5.3, I don't understand why you would want to allow an
  opportunistic mode at all. Whether your preference is DANE
  or WebPKI, we're certainly at a point where authentic
  server identities are readily available, so why make
  life complicated?

-Ekr

---

From: Rob Sayre <[email-masked]>
Date: Tue, 29 Oct 2019 16:23:03 -0700

> - An A record for ns.service.example in the additional

Hypothetically, one might consider the best way to sell $10k "security"
boxes that don't do all that much.

thanks,
Rob

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Oct 2019 16:59:34 -0700

> boxes that don't do all that much.

Sorry, I think you're going to have to unpack this a bit.

-Ekr

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 30 Oct 2019 18:07:28 +0000

Very helpful feedback! I recorded this as an issue to track down the last 2 segments of your mail since those are very actionable.

Jason

https://github.com/alex-nicat/ietf-dprive-phase2-requirements/issues/10

From: dns-privacy <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Date: Tuesday, October 29, 2019 at 7:02 PM
To: "[email-masked]" <[email-masked]>
Subject: [dns-privacy] Comments on draft-lmo-dprive-phase2-requirements-00.txt

After reviewing this draft, it is not clear to me what architectural
model people have in mind. At a high level, say that I attempt to
dereference example.com<http://example.com> and I have a cached NS record for .com. So, I
query example.com<http://example.com> and get back:

Given this information, I then connect to ns.service.example
given this IP and query for example.com<http://example.com>. So what happens when
we introduce TLS into the equation? In particular:

-Ekr