I took some time to read over draft-wijngaards-dnsop-confidentialdns-03
carefully and take some notes.
Some comments below. Overall the ideas here are interesting and worthy
of continued work, but the i-d does not seem ready for WG adoption in
its current state.
My biggest concern is comment (c) below: if I understand it correctly,
the i-d seems an interaction between privacy choices for zone operators
and connections that seems surprising.
-John Heidemann
----------------------------------------------------------------------
My comments are based on the text of
draft-wijngaards-dnsop-confidentialdns-03.
I consulted the slides from IETF-92 for context,
but my comments are based on the i-d text.
overall comments:
a. I had some trouble identifying the assumptions and constraints the
document starts with. While those assumptions not part of the potential
standard, it is difficult to assess if the document meets its goals
without making the constraints clearer. (It looks like the goals are to
run with just new RRs and minimal changes to round trips, but that's my
guess.) A revision may want to explicitly discuss the constraints in
the introduction.
b. One requirement that is important is if a goal is opportunistic or
mandatory privacy. The introduction is clear about opportunistic ("As
this is opportunistic encryption..."). I misread that is indicating
this i-d does only opportunistic encryption.
The introduction mentions mandatory privacy ("authenticated mode") in the
last paragraph, but I did not understand what that means until section 4
because the last paragraph of the introduction focuses on the mechanism
and not the property that mechanism provides. (That is, it talks talks
about keys and not that authenticated mode produces guaranteed privacy.)
Ideally a revision would make the goals of the mechanisms clearer.
c. An important question in DNS privacy is WHO or WHAT is kept
private--is privacy a property of client-server connections, or of
zones? I had assumed most DPRIVE proposals were only about connection
privacy only. In reading this i-d, I'm not sure what confidential DNS
proposes.
Specifically, "Authenticated Operation" seems to make mandatory privacy
a property of the zone (or perhaps domain name suffix). Discussion of
fallback lets the zone owner set a flag that will force all clients to
fail DNS queries if they cannot get private communication.
Use of "." in the ENCRYPT query also has potential confusion. Does this
mean encryption for "*." (everything under the root?). What if I ask
for QTYPE=ENCRYPT, QNAME="com."? See also comment (d) below.
It seems problematic to mix domains and connections as the definition of
privacy. While some domains may seem to demand privacy (aa.org or
Warren's more evocative examples), I'm not sure even a "sensitive"
domain must ALWAYS be private (perhaps it can be open within a trusted
organization, like my company or my house). In my view, the choice of
privacy here should be a property of the DNS operator (me) not the zone
operator.
It also seems problematic if aa.org were to demand privacy on their
name. They won't get it for legacy clients (that don't know about
ENCRYPT), and they will deny access to new, ENCRYPT-aware clients that
choose not to do encryption. It seems to me like privacy is the policy
of a client and its next-hop resolver, not the zone operator. (The user
and recursive resolver for DPRIVE.)
Detailed comments:
section 3 Server and Client Algorithm:
d. "If a clients wants to fetch the keys for the server from the
server...": what is "the server" here? The server for the root zone, or
some arbitrary server? If "." just just client/server signaling, then
shouldn't the query be specific to the server?
Other protocols use QCLASS=CH to indicate connection-level signaling
(for example rfc-4892). If that's what's intended, the i-d may wish to
do something similar.
e. "If a client wants to perform an encrypted query, it sends...": the
purpose of this exchange is unclear to me. Is the goal to implement key
exchange? If so, is it sufficient implement an existing protocol?
Which protocol is it implementing? I'm worried about trying to invent a
new key-exchange protocol--it seems easy to accidentally introduce
vulnerabilities.
f. As one possible example of a key-exchange weakness, take "If the
client wants to use a symmetric key, it omits the KEYs, and instead
includes an ENCRYPT of type SYM in the authority section. The ENCRYPT
of type RRs then follows after the SYM and can be encrypted with the key
from that SYM.": if you get your symmetric key in the cleartext reply
to ENCRYPT, isn't the this key visible to any eavesdropper?
section 4. Authenticated Operation
g. "The previous documented...". Do you mean "The previous SECTION
documented..."?
h. "This removes a full roundtrip...": removes relative to what?
(Presumably not the non-private UDP query :-)
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
