Subject: Re: I-D Action:draft-barwood-dnsext-dns-transport-18.txt

From: Nicolas Williams <[email-masked]>
Date: Wed, 7 Apr 2010 15:59:02 -0500

On Wed, Apr 07, 2010 at 01:45:01PM -0700, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : DNS Transport
> 	Author(s)       : G. Barwood
> 	Filename        : draft-barwood-dnsext-dns-transport-18.txt
> 	Pages           : 12
> 	Date            : 2010-04-07
> 
> This document describes a new transport protocol for DNS.
> IP fragmentation is avoided, blind spoofing, amplification attacks
> and other denial of service attacks are prevented. Latency for a 
> typical DNS query is a single round trip, after a setup handshake.
> No per-client server state is required between transactions.
> Packets may optionally be encrypted and authenticated.
> The protocol may have other applications.

Where is this being discussed?

Why is SERVERTOKEN 32 bits?  Have we not learned yet that 32 bits is not
enough?  Why does the client's IP address have to be any part of the
computation of SERVERTOKEN?

Why is the OPCODE 16 bits followed by a 32-bit value?  This completely
screws up alignment.

Where's the 12-byte transaction ID that's mentioned in section 3.1?

Is a response paging protocol that requires server state really better
than IP fragmentation?  I'd rather we have a hash (MAC!) of the message
data included in the response, to make it possible to detect attacks on
IP reassembly.  (The MAC key could just be the SERVERTOKEN or issued by
the server when it issues the SERVERTOKEN.)

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 7 Apr 2010 16:10:50 -0500

Security-wise it'd be better to have the initial part of the protocol
work like this:

C->S: here's a client_nonce, gimme a token

S:    <compute token = server_key_id || server_nonce ||
                       MAC(server_key, server_nonce || client_nonce)

S->C: here's your token

Nonces should be at least 64 bits.  server_key_id serves as an
expiration time as well, but if desired an explicit expiration can be
added.

This would work with anycasting (servers can validate tokens without
keeping any state other than the server keys).  And it'd not bind in
client IP addresses, thus there'd never be problems with mobility or
NAT.

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Apr 2010 10:16:49 -0700

>Where is this being discussed?

The DNSEXT WG.

--Paul Hoffman, Director
--VPN Consortium