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

From: Mukund Sivaraman <[email-masked]>
Date: Sun, 27 Sep 2015 00:45:52 +0530

Hi everybody

On Sat, Sep 26, 2015 at 12:10:09PM -0700, [email-masked] wrote:
> 
> A new version of I-D, draft-muks-dns-message-checksums-00.txt
> has been successfully submitted by Mukund Sivaraman and posted to the
> IETF repository.
> 
> Name:		draft-muks-dns-message-checksums
> Revision:	00
> Title:		DNS message checksums
> Document date:	2015-09-27
> Group:		Individual Submission
> Pages:		7
> URL:            https://www.ietf.org/internet-drafts/draft-muks-dns-message-checksums-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-muks-dns-message-checksums/
> Htmlized:       https://tools.ietf.org/html/draft-muks-dns-message-checksums-00
> 
> 
> Abstract:
>    This document describes a method for a client to be able to verify
>    that IP-layer PDU fragments of a UDP DNS message have not been
>    spoofed by an off-path attacker.

This is a new draft on DNS message checksums. I look forward to hearing
review comments.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Sun, 27 Sep 2015 05:39:08 +0530

> >    spoofed by an off-path attacker.

The NONCE-COPY field seems redundant now as the checksum computation
includes the NONCE field. It was added in an earlier form of the draft
when the computation didn't include the nonce. Perhaps it can be removed
and the NONCE field doubled in size.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Sun, 27 Sep 2015 08:29:14 +0530

Hi Paul

I'm CC'ing this reply to the dnsop@ list as it is relevant info for
others to read too. So I've not quoted your email.

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. It is a simpler
lesser form of DNS cookies that goes a little further from the client's
perspective.

If some countermeasures such as source port randomization are either
turned off (perhaps when DNS cookies are in use; typically source port
randomization has a significant performance penalty) or ineffective
perhaps due to NAT, there is a remote possibility of poisoning with IP
fragmentation.

Note that this draft still cannot prevent some kinds of attack such as
response and NS blocking and NS pinning as described in Herzberg and
Shulman's paper (cited in the draft).

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. With iteration, it can result in conspicuously
increased average turnaround time in applications such as web-browsing
as DNS is the starting point. This becomes noticable in a location such
as where I live (India) from where the RTT to many of the
mediumly-popular websites' DNS nameservers is quite high. There are some
efforts to solve this such as TCP fast open, but not widely
deployed. Once the records are cached everything is faster, but a delay
is still a delay. RTT to almost everywhere significant is high from
here. Also, OTOH, use of DNS cookies with UDP itself may require
additional roundtrips.

2. There are concerns on whether using TCP is scalable for DNS. The
dns-dev-coord list was setup to discuss this topic and try to improve
TCP performance across implementations.

But I agree, TCP-only is becoming more and more appealing/relevant with
the number of issues in using UDP.

		Mukund

---

From: Paul Wouters <[email-masked]>
Date: Mon, 28 Sep 2015 10:39:04 -0400 (EDT)

On Sun, 27 Sep 2015, Mukund Sivaraman wrote:

> 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.

> 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.

This draft also does nothing for on-path attackers.

Paul

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 28 Sep 2015 21:18:52 +0530

Hi Paul

> 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.

> 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

---

From: Paul Vixie <[email-masked]>
Date: Mon, 28 Sep 2015 09:56:38 -0700

> cookies too. This draft intends to provide a method without the use of

noone has ever regretted adding an end-to-end checksum to any system.

many have regretted trusting the lower-level network to deliver things
perfectly.

so i think there's good cause to add a DNS-level checksum even as we add
DNS-level cookies.

for extra credit, make it work on IXFR and AXFR as well (for the whole
session, not just per-message.)

-- 
Paul Vixie

---

From: Robert Edmonds <[email-masked]>
Date: Mon, 28 Sep 2015 13:30:28 -0400

> This is a new draft on DNS message checksums. I look forward to hearing

Hi, Mukund:

16 bits is an awful lot of space for the ALGORITHM field.  Compare to
the DNSSEC algorithm number field, which is only 8 bits.

-- 
Robert Edmonds

---

From: Mukund Sivaraman <[email-masked]>
Date: Mon, 28 Sep 2015 23:02:56 +0530

Hi Robert

> the DNSSEC algorithm number field, which is only 8 bits.

Do you suggest changing it to 8 bits too?

		Mukund

---

From: Evan Hunt <[email-masked]>
Date: Mon, 28 Sep 2015 17:40:36 +0000

> so i think there's good cause to add a DNS-level checksum even as we add

+1

I would prefer to use checksum and cookies in parallel rather than have
the checksum option recapitulate cookie functionality, though.  Unless I'm
overlooking something, the NONCE field in Mukund's proposal becomes
unnecessary if cookies are in use. Otherwise it seems like a very good
idea.

(It's a pity there's no version field in the COOKIE option format;
COOKIE version 1 could have been extended to include a checksum.)

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Robert Edmonds <[email-masked]>
Date: Mon, 28 Sep 2015 14:20:04 -0400

> Do you suggest changing it to 8 bits too?

If you keep an algorithm field, yes, I suggest changing it to 8 bits.
It seems unlikely more than one or two algorithms would ever be
implemented.  Is algorithm agility really needed, though, given that
there are ~65000 unused EDNS0 option codes?

I am also curious why a cryptographic hash function (SHA-1) is needed
for this.  Is a fast non-cryptographic checksum not suitable (e.g.,
CRC-32C, which can be computed in hardware on x86 CPUs)?

Also, there is a long deployment tail for new EDNS options.  If it's
urgent to deploy a countermeasure against off-path fragment spoofing,
why not something like Unbound's "referral path hardening", or
advertising a smaller EDNS buffer size which is much less likely to
result in fragmentation?  (E.g., I believe OpenDNS advertises a ~1.4
Kbyte EDNS buffer size.)  Those countermeasures can be deployed
unilaterally by the resolver, and on a shorter time scale than a new
EDNS option.

-- 
Robert Edmonds

---

From: Paul Vixie <[email-masked]>
Date: Mon, 28 Sep 2015 11:25:53 -0700

Robert Edmonds wrote:
> ...

in currently theorized attacks, the udp checksum is fooled by altering
two parts of a fragment:

first, alter the part you want to use to inject poison into a cache.

second, alter something else to fix up the checksum based on the first
alteration.

if CRC-32C is immune to that attack, i havn't heard, but i'd believe.

> unilaterally by the resolver, and on a shorter time scale than a new

those things should also be done in the short term.

but it's the internet. it'll outlive us all. we ought to have a long
term plan as well.

-- 
Paul Vixie

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 28 Sep 2015 11:31:32 -0700

> if CRC-32C is immune to that attack, i havn't heard, but i'd believe.

Note that he said "e.g.". There are other algorithms much faster than 
SHA-1 that would work as well, such as the one in draft-eastlake-fnv.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Mon, 28 Sep 2015 14:36:25 -0400 (EDT)

> but it's the internet. it'll outlive us all. we ought to have a long

It's called DNSSEC.

Paul

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 29 Sep 2015 10:12:59 +0530

Hi Robert

> If you keep an algorithm field, yes, I suggest changing it to 8 bits.

OK. I'll make this change. :)

> there are ~65000 unused EDNS0 option codes?

If I follow correctly, what you're suggesting is that if an algorithm
becomes weak, we jump to a new EDNS option which has a different EDNS
option code assigned. This seems like a bad idea to me, because as such
option codes get assigned, they will be spread out and the code in DNS
implementations which handle it will look dirty. It's better to keep it
all under one option code, even if it occupies 1 more byte.

> CRC-32C, which can be computed in hardware on x86 CPUs)?

SHA-1 was chosen without too much consideration for anything. Appendix A
was empty initially and SHA-1 was added as a placeholder to fill that
section. The list of algorithms is best decided by discussion here, and
SHA-1 can be removed if it is unsuitable.

On the topic, I'll add a penny: checksum algorithms (as we want them
here) have two extremes, one of which is to protect against accidental
modifications of data, and another which is to protect against
malicious/intentional modification of data. There are also others such
as hashing functions (uniform distribution in the mapped output range,
or something more specific). All these have different performance
characteristics.

CRCs serve towards the "accidental modifications" category, and SHA-1
towards the "intentional modification" one. We want something suitable
in the latter category, a cryptographic hash function, though the level
of security it provides need not be as high as that expected for a
long-lived signature.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 29 Sep 2015 10:23:46 +0530

Hi Paul

> >but it's the internet. it'll outlive us all. we ought to have a long

Zone data validation and DNS message validation are two different
concepts. DNSSEC will not protect against DNS message modifications.

DNSSEC provides support for end-to-end security (complete chain-of-trust
signature verification), something that a DNS message checksum/signature
cannot provide. On the other hand, DNSSEC requires signatures for each
RRset bloating messages, whereas a DNS message checksum/signature is
usually smaller as there is 1 per message.

Anyway, I'll explain with an example why DNSSEC is not sufficient to
protect against DNS message modifications. Assume a company provides a
service in different countries. They want users in each country to use
the local CDN only, let's assume because users have no route to other
CDNs outside the country or because it's too expensive to service data
from other countries. They use views in DNS, each serving a different
country and the A/AAAA records returned by the authoritative server
provides the correct IP address for that country. Assume that zones in
these views are signed using the same KSK/ZSK.

This will work fine, but an attacker who has access to country A's
response may succeed in poisoning a message in country B with A's data
and DNSSEC validation will not catch it. DNSSEC protects each RRset, but
not the DNS message.

Also, there are other items in a DNS message aside from just signed zone
data.

		Mukund

---

From: Paul Wouters <[email-masked]>
Date: Tue, 29 Sep 2015 01:33:57 -0400 (EDT)

On Tue, 29 Sep 2015, Mukund Sivaraman wrote:

> On the other hand, DNSSEC requires signatures for each RRset bloating messages

Just like TLS is bloating HTTP? :)

> and DNSSEC validation will not catch it. DNSSEC protects each RRset, but

Such a powerful attacker can also just reroute or NAT the IP addresses
of the one CDN to the other. Sure, it might be annoying to you but since
it is still using DNSSEC validated data that you deem valid for some
clients, it shouldn't be the end of the world either.

I'm not convinced this draft is worth doing. But I don't see it causing
much harm either.

Paul

---

From: Mukund Sivaraman <[email-masked]>
Date: Tue, 29 Sep 2015 11:21:12 +0530

Hi Paul

> Just like TLS is bloating HTTP? :)

TLS and HTTP are irrelevant here, no? The bloat by RRSIGs, considering
just sizes, would be worse than that of TLS and HTTP per amount of data.

> clients, it shouldn't be the end of the world either.

The example I mentioned is still the case of an off-path attacker. For
an attacker in country B, just having a shell account in country A will
be sufficient to gather signed A/AAAA records for country A.

It would be the end of the world if the poisoned address is not routable
in that location.

The point is that zone data validation doesn't automatically guarantee
that the DNS message is trustworthy.

		Mukund

---

From: Davey Song <[email-masked]>
Date: Thu, 1 Oct 2015 04:02:22 +0800

Hi Mukund，

I review the problem statement in this draft: the cache poison threat during IP fragmentation. I think we address and try to solve  this problem by application-level fragment draft, right?   I would like to introduce this draft into this thread. Hopefully more people can read this draft and compare the merit of the two approaches. I personally prefer application-lelvel fragment because it is a cure for a broader problems, the old problem related packs size and IP fragmentation.

***********************************************************************
 A New Internet-Draft is available from the on-line Internet-Drafts directories.

       Title           : DNS message fragments
       Authors         : Mukund Sivaraman
                         Shane Kerr
                         Linjian Song
	Filename        : draft-muks-dns-message-fragments-00.txt
	Pages           : 13
	Date            : 2015-07-20

Abstract:
  This document describes a method to transmit DNS messages over
  multiple UDP datagrams by fragmenting them at the application layer.
  The objective is to allow authoriative servers to successfully reply
  to DNS queries via UDP using multiple smaller datagrams, where larger
  datagrams may not pass through the network successfully.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-muks-dns-message-fragments/ <https://datatracker.ietf.org/doc/draft-muks-dns-message-fragments/>

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-muks-dns-message-fragments-00 <https://tools.ietf.org/html/draft-muks-dns-message-fragments-00>

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>

> 在 2015年9月27日，03:15，Mukund Sivaraman <[email-masked] <mailto:[email-masked]>> 写道：
> 
> Hi everybody
> 
> On Sat, Sep 26, 2015 at 12:10:09PM -0700, [email-masked] <mailto:[email-masked]> wrote:
>> 
>> URL:            https://www.ietf.org/internet-drafts/draft-muks-dns-message-checksums-00.txt <https://www.ietf.org/internet-drafts/draft-muks-dns-message-checksums-00.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-muks-dns-message-checksums/ <https://datatracker.ietf.org/doc/draft-muks-dns-message-checksums/>
>> Htmlized:       https://tools.ietf.org/html/draft-muks-dns-message-checksums-00 <https://tools.ietf.org/html/draft-muks-dns-message-checksums-00>
>> 
>> 
>> Abstract:
> _______________________________________________
> DNSOP mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop

------------------------------
Davey Song(宋林健)
BII Lab
[email-masked] <mailto:[email-masked]>

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 30 Sep 2015 17:16:38 -0700

> and DNSSEC validation will not catch it. DNSSEC protects each RRset, but

This is accepted risk signatures can be reused for the interval specified,
for any purpose.

> As your schema is useless against on-path attacker I recommend you take a
look at
making TKEY +TSIG easier to use, then we get the good property of message
integrity.

Olafur