Re: [DNSOP] draft-hzhwm-start-tls-for-dns-00: Starting TLS over DNS

[Tony Finch <[e-mail]>]

Zi Hu <[e-mail]> wrote:

> We recently posted draft-hzhwm-start-tls-for-dns-00 ("Starting TLS over
> DNS") to explore one proposal to add standard TLS over standard DNS to
> improve privacy.

I like this. The general approach of the extension looks sensible to me.

Some comments:

   This document defines only the protocol extensions necessary to
   support TLS negotiation.  It does not describe how DNS clients might
   validate server certificates or specify trusted certificate
   authorities.  Solutions for certificate authentication are outside
   the scope of this document.

This absolutely needs to be defined before the protocol is deployed and I
think it is a huge mistake to rule it out of scope.

SMTP made this mistake (RFC 3207) and as a result most certificates
offered by SMTP servers cannot be validated, and SMTP over TLS is
vulnerable to MITM attacks. Fixing this is a huge headache. I don't
want to see it happen again.

But solving this problem is really hard especially in this context :-(

A DANE-like approach might work for authoritative servers.

Dunno about stub <-> recursive connections...

2.1.2.  Receiving Responses

   A DNS client that receives a response using UDP transport that has
   the TO bit set MUST handle that response as usual.  It MAY record the
   server's support for DNS-over-TLS and use that information as part of
   its server selection algorithm in the case where multiple servers are
   available to service a particular query.  [For discussion: UDP is
   subject to spoofing and a client which depends on TO=1 in a UDP
   response may be tricked into never upgrading to TLS.]

This is also true for DNS over TCP. It would be nice to have some stronger
protection against downgrade attacks. Point 3 in the security
considerations needs more thought.

   A DNS client that receives a response to its initial query using TCP
   transport that has the TO bit clear MUST not initiate a TLS handshake
   and SHOULD utilize the existing TCP connection for subsequent
   queries.

I think in this situation it would be better for the client to go back to
using UDP. Existing DNS servers do not handle TCP queries concurrently, so
the client will suffer much worse performance by continuing to use TCP.

2.4.  Middleboxes

   2.  The DNS client sends a TO=1 query and receives a TO=1 response,
       but the TLS handshake fails because the server's certificate
       cannot be authenticated.  In this case the client SHOULD close
       the established connection and fall back to unencrypted DNS for a
       reasonable period (as discussed in Section 2.1.2).

Having said that certificate validation is really important, I still think
that unauthenticated encryption is strictly better than nothing, since it
defeats passive (but not active) eavesdropping. But this kind of soft
failure is a great way to introduce downgrade attacks.

3.  Performance Considerations

This section should require servers to handle DNS queries over TCP and TLS
concurrently. They should be prepared to send responses as soon as they
are available, and out of order when necessary, to avoid head-of-line
blocking. This minimises the performance penalty relative to UDP.

Tony.
-- 
f.anthony.n.finch  <[e-mail]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.