Subject: [dns-privacy] draft-ietf-dprive-start-tls-for-dns-00 comments

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 07 May 2015 21:38:55 -0400

Hi all--

Thanks for the start-tls-for-dns draft!  i'm happy to see it.  I have a
few pieces of feedback below...

------

A structural nit: the draft has no Table of Contents -- can you update
whatever drafting toolchain you're using to include one?  they're
helpful for people trying to navigate the document.

------

The third bullet point in section 2.2 of
https://tools.ietf.org/html/draft-ietf-dprive-start-tls-for-dns-00 says:

   o  The DNS client sends a TO=1 query and receives a TO=1 response,
      but the middlebox does not understand the TLS negotiation and does
      not allow those packets to pass through.

"those packets" is confusing here -- my first reading of it took me a
couple tries to see that it wasn't talking about the query and response
in the first sentence.  It should probably say "does not allow the TLS
handshake packets to pass".

------

section 3.1 says:

   Opportunistic privacy can be used by any current client, but it only
   provides privacy when there are no on-path attackers.

It should probably say "no on-path active attackers", since it still
provides privacy against on-path passive eavesdroppers.

------

section 3.2 says:

   With pre-deployed privacy, a client retains a copy of the TLS
   certificate and IP address of each provider.  The client will only
   use one of those DNS providers.  Because it has a pre-deployed TLS
   certificate, it may detect person-in-the-middle and downgrade
   attacks.

I'm not sure that "certificate" is the relevant thing that a client
wants to cache here.  For example, a client could instead use one of the
following options:

 * a long-term public key (and the certificate itself could be
   re-issued as long as it retains the same key, or could be sent as a
   raw public key (RFC 7250), or a TLSA record, etc)

 * the equivalent of an HPKP pinset (a digest of two or more public
   keys that should be present somewhere in the certificate chain) plus
   a name of the peer

 * a PSK, for use with one of the TLS PSK modes

 * the name of the peer and a X.509 trust anchor list

Or maybe some combination of the above.  I'm not sure that this draft is
the place to specify all of these options, of course, but limiting it to
"the TLS certificate of each provider" seems unnecssesarily
constrained.  (This is partly addressed in item 4 of the security
considerations section, but seems to be in conflict)

------

DNSSEC-trigger is mentioned but has no reference.  perhaps a pointer to
https://www.nlnetlabs.nl/projects/dnssec-trigger/ or somewhere else
would be worth including?

------

The Security Considerations section does not mention traffic analysis at
all.  The sizes of DNS packets and their timing may turn out to be
significant, and this draft should at least mention these concerns.

------

There is no Privacy Considerations section, but there probably should
be.  RFC 6973 is a good resource here.

------

The draft mentions TCP Fast Open; it may also want to mention the
TLS False Start protocol optimization:

  https://tools.ietf.org/html/draft-ietf-tls-falsestart-00

------

hope these comments are helpful,

          --dkg