On Tue, Jul 3, 2018 at 2:39 PM Allison Mankin <[email protected]> wrote:
> Please take a look at a new individual internet-draft we will
> introduce at the Montreal DPRIVE meeting, targeted eventually for
> Experimental.
I've read draft-annee-dprive-oblivious-dns-00. At a high level I
found the idea interesting: decoupling DNS query details from client's
source IP address. On the other hand the current version of the draft
lacks many necessary details to actually implement the idea, and
(maybe partly because of that) I have questions on its technical
details and deployability. So at this moment I'm not sure if I
support this particular protocol for eventual WG adoption or
publication.
Some specific points follow:
- I hope the next version will specify at least the following details
as a protocol specification, that is, in a way that someone can
write an interoperable implementation just by reading it:
+ how to build (including encryption) the obfuscated query name
+ how to include the encrypted session key in the query (assuming
it's an EDNS option, with a specific option format)
+ how to exchange the ODNS server's public key (ditto)
- the current version of the draft seems to intend to use EDNS options
for exchanging session and public keys, and expect intermediate
recursive servers to "forward" the options to ODNS authoritative
servers. But since EDNS is a hop-by-hop protocol, you cannot just
assume such a behavior; it must be part of the protocol
specification in, e.g., a "recursive server behavior" section (this
is what I tried to say at the mic in the meeting). And then it
means we need to update all relevant recursive servers for ODNS to
work, so I suspect this claim of section 2 is a bit too strong:
"ODNS operates in the context of the existing DNS protocol, allowing the
existing deployed infrastructure to remain unchanged".
- If we use a (set of?) well-known domain suffixes to distinguish
ODNS-encrypted qnames from other general names, and if the basic
motivation is that we really don't trust the recursive server
operators, then I'm afraid we should also worry about those
operators "blocking" these suffixes. If they are well-known it's
pretty easy, and many commercial operators already have and use a
framework (such as RPZ) to make it possible.
- In Section 3 the draft refers to ECS and states: "ODNS hides a
client's IP address from the authoritative name servers at different
levels of the DNS hierarchy". But ECS already provides a
privacy-conscious client with a way to hide it address from
authoritative servers, so it doesn't seem to be a particular
advantage of ODNS.
- I'm afraid we need more careful assessment on scalability issues.
The current draft mentions anycast for scalability concerns. It may
work, but unlike other anycast authoritative servers in the DNS,
ODNS authoritative servers need to handle queries for the entire
name space (they can't just "delegate" the load); and unlike other
anycast recursive servers an ODNS anycast instance needs to handle all
(essentially) recursive queries in that anycast domain. It may
still work, but it doesn't seem to be so obvious to me. (In the end
we may not be able to be sure until we have large scale
experiments).
--
JINMEI, Tatuya
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
