-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi John,
On 23/04/15 17:24, John Heidemann wrote:
>
> 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.
Thank you for your review, it looks like that text needs to be revised.
> 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.
The "." name is because it is short. It is supposedly per-server. It
is true that for the 'authenticated' operation, key distribution uses
zone names (so it can be put in the DNS). But for the opportunistic
part, the name is irrelevant. Perhaps it should use class CH for that
exchange.
Yes it is a key exchange, but not an established RFC; so it likely has
defects.
Best regards,
Wouter
>
> -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
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJVOf6OAAoJEJ9vHC1+BF+NCOQP/jOrjWPqT4/JFY0tus3yUZYS
0YKqGwu0uCDmh4NgVg7jMysqoGpxaG4825216XCWVpOdGs98hc19klF9VKcBLfc3
wRSBguKp35vvLX0bA9ZtRYZ/64r+UfdzZ1XSqlvS+rViS8ckQNY2qKiea6+stmAp
hyy3A2MUOCA4kEpCcKujMWA5Nu3q9hgvSvnOc2KzfA6NYl61SzvlM39TqA0OfUgh
+31b2phYaAu/h62PsU9rNvxhcbZgnfqZIxMHkHCswZjaFJFRxtQpTmGxhDp1O8Oq
FiWDEEqLpzMN9agy50BWb0Y8Y+EPpB8gIZbs9h8liLsBIEgqrCaVS2CZYo6PMiJ3
Z/+bbXBKRg2d5CJbCSx6A0hLSbnPQJKvKGz1nz1Mo2PJmrQ9k8V7pCak5eV9G24g
Tm2EBTNRIS0zFS8XvMYgwNHNdWbDic/EZdve4662d7eO3gn7uuo+6HOPTG3QclcN
nn35ZH8cXCHz+rK5X0ZHRvxlXnbZhSz5i2+SI3nsR1RA9GVVDoBpadv2LnmOC3NF
ZjD2urMGI3As2SVwWuMFSz9cy5mzAyb5O+LqWRF4wNWEzszWvWJXn1vouhwhf2Qy
4zRfv9jJFBvdiimuoWuWhe3N10bJzg/0HNlKpKruqJ9Al++ZcIOPV4W92A0tJdDl
he9KcUOcYu9FgMMyxOh8
=Neg+
-----END PGP SIGNATURE-----
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
