Subject: [dns-privacy] comments on draft-wijngaards-dnsop-confidentialdns-03

From: John Heidemann <[email-masked]>
Date: Thu, 23 Apr 2015 08:24:40 -0700

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 :-)

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Fri, 24 Apr 2015 10:27:58 +0200

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

> 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.)
> 
> 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:
> 
> 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?
> 
> 
> g. "The previous documented...".  Do you mean "The previous
> SECTION documented..."?
> 
> _______________________________________________ dns-privacy mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 24 Apr 2015 11:48:37 +0300

On Fri, Apr 24, 2015 at 10:27:58AM +0200, W.C.A. Wijngaards wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> Hi John,
> 

Some of the deflects:

1) Uses RSA key exchange, which is regarded as obsolete.

The modern way is to use forward-secure (elliptic-curve) Diffie-Hellman
key exchange with designated groups.

Then hash the DH result and messages involved in key exchange into
session keys.

For authentication, either mix in results of type short-lived x
long-lived (which tends to lead to deniable key exchange) or
use signatures over important messages (not deniable).

(TLS 1.3 drops support for RSA kex and non-designed group Diffie-
Hellman, both were supported in TLS 1.2).

2) Seemingly uses unauthenticated encryption, which is a major
no-no.

Unless one is doing something exotic, just use standard-issue
AEAD ciphers (RFC5116).

With unauthenticated encryption, by playing with ciphertexts,
one often can break the system in various ways, often leading
to attackers successfully decrypting messages.

3) Uses CBC mode. That one has all sorts of weird issues.

See above.

-Ilari