Re: [DNSOP] New Version Notification for draft-muks-dns-message-checksums-00.txt

[Mukund Sivaraman <[e-mail]>]

Hi Paul

On Mon, Sep 28, 2015 at 10:39:04AM -0400, Paul Wouters wrote:
> On Sun, 27 Sep 2015, Mukund Sivaraman wrote:
> 
> >UDP has a header checksum that can notice message modification when in
> >use. Sometimes this may be 0 if the sender host did not generate a
> >checksum. This draft adds one in the application layer alongside a nonce
> >known to the client. Together they are meant to thwart any possibility
> >of different kinds of off-path cache-poisoning attacks.
> 
> There is other work happening that accomplishes the same. The DPRIVE
> work to add TLS and longlived TCP, the dns cookies, and of course
> DNSSEC itself. I don't really see the need to add another mechanism to
> help against non-DNSSEC spoofing attacks.

DNS cookies do not protect against IP fragmentation - they do not check
the message contents. These same things above can be said for DNS
cookies too. This draft intends to provide a method without the use of
additional roundtrips.

> >There are practical issues with TCP which are still currently prevelant:
> >
> >1. The 3 way handshake doubles the number of roundtrips necessary before
> >an answer is received.
> 
> But with clarifications like edns-tcp-keepalive, we are hoping that
> clients can keep TCP connections to resolvers open for much longer,
> so that TCP does not really have more overhead than UDP.

It is not the connection between a client to resolver, but the
connections between a resolver and authoritative servers that is a
bottleneck during iteration.

Keepalive doesn't help the initial connection establishment time. One
can make a similar argument that once the data is cached, it's a lot
faster.

I mention the case of initial iteration during lookup of any new
website, which is often the case with smaller local resolvers.

> This draft also does nothing for on-path attackers.

I have been considering this case ever since you mentioned it (in direct
email). It is difficult to achieve this without using some kind of
shared secret or public key method.

1. If any method used involves additional roundtrips for things like key
retrival, TCP is a better bet. It will likely become a better option
anyway one day.

2. If the zone is DNSSEC signed, then that is a better way to protect
against forgery rather than using DNS message signatures.

For unsigned zones, if it's possible to protect against forgery without
additional roundtrips with a light-weight signature, it would definitely
help and prevent on-path attackers. I have a scheme in mind for this,
and I'll come back with an update once it settles down, but this would
involve a chain-of-trust (where DNSSEC can be re-used where available).

For unsigned zones and vanilla serving, I think the checksum draft is
relevant as long as they exist.

		Mukund