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 protected]> on behalf of Eric Rescorla <[email protected]> Date: Tuesday, October 29, 2019 at 7:02 PM To: "[email protected]" <[email protected]> Subject: [dns-privacy] Comments on draft-lmo-dprive-phase2-requirements-00.txt 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<http://example.com> and I have a cached NS record for .com. So, I query example.com<http://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<http://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
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
