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

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

Hi everybody

This draft was updated with a new name (thanks to Tomek Mrugalski for
pointing this out, nits, and other things) and with the following
changes:

   o  draft-muks-dnsop-dns-message-checksums-00
      Initial draft (renamed version).  Removed the NONCE-COPY field as
      it is no longer necessary.  Doubled the size of the NONCE field to
      128 bits.  Added sample checksum algorithms.  Fixed incorrect
      reference, language and grammar.

----- Forwarded message from [email-masked] -----

Date: Mon, 28 Sep 2015 07:53:47 -0700
From: [email-masked]
To: Mukund Sivaraman <[email-masked]>, Mukund Sivaraman <[email-masked]>
Subject: New Version Notification for draft-muks-dnsop-dns-message-checksums-00.txt
Message-ID: <[email-masked]>

A new version of I-D, draft-muks-dnsop-dns-message-checksums-00.txt
has been successfully submitted by Mukund Sivaraman and posted to the
IETF repository.

Name:		draft-muks-dnsop-dns-message-checksums
Revision:	00
Title:		DNS message checksums
Document date:	2015-09-28
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/internet-drafts/draft-muks-dnsop-dns-message-checksums-00.txt
Status:         https://datatracker.ietf.org/doc/draft-muks-dnsop-dns-message-checksums/
Htmlized:       https://tools.ietf.org/html/draft-muks-dnsop-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.

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.

The IETF Secretariat

----- End forwarded message -----

		Mukund

---

From: "Joe Abley" <[email-masked]>
Date: Mon, 28 Sep 2015 19:53:10 -0400

>    reference, language and grammar.

                    +-------+-------+-----------------+
                    | Value | Type  | Status, Remarks |
                    +-------+-------+-----------------+
                    | 0     | EMPTY | Empty digest    |
                    | 1     | SHA-1 | Mandatory       |
                    +-------+-------+-----------------+

Reserving other values for private use might be useful.

The document doesn't describe the expected behaviour when a DNS server receives a DNS message with a CHECKSUM option that specifies an algorithm that is unknown by the receiver.

The IANA Considerations section seems inadequate -- it might be worth reviewing RFC 5226 and fleshing out the text that instantiates this registry (or anticipating the smooth passage of draft-leiba-cotton-iana-5226bis-11 and reading that instead for the same reason).

The Security Considerations section should say more about the limitations of this approach, e.g. the ability of an off-path attacker to correct for changes that would change a checksum with other changes that will restore it, which is my lazy précis of the no-doubt more succinct observation that Vixie made somewhere in this thread (or another thread near it).

The primary point of this draft is to offer some degree of integrity protection for unsigned responses (since signed responses already have it); it might be useful to spell that out. If I receive a query with the CHECKSUM option which I support, but I know I'm going to return signed data (and DO=1 in the query) I might decide to pretend I don't implement CHECKSUM because it's not especially useful if I have RRSIGs to tell you about. Does the receiver of my response get to assume that I don't support CHECKSUM at all, and never ask for it again?

If I send a query with the CHECKSUM option to a server (or through a middlebox) that doesn't handle unknown EDNS(0) option types correctly, and I hear no response, what should I do? If I receive something else unexpected (like a FORMERR), what should I do? Not accommodating the errors of others might well be the right thing, here, but we know that end users don't care about technical correctness when "you are broken but my neighbour's ISP is fine" and hence there will be pressure to mitigate the failures of others in some way or other. Having different implementations fall back differently seems less than desirable.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Tue, 29 Sep 2015 12:17:07 +1000

In message <[email-masked]>, "Joe Abley" writ
es:
> The document doesn't describe the expected behaviour when a DNS server
> receives a DNS message with a CHECKSUM option that specifies an algorithm
> that is unknown by the receiver.
>
> The IANA Considerations section seems inadequate -- it might be worth
> reviewing RFC 5226 and fleshing out the text that instantiates this
> registry (or anticipating the smooth passage of
> draft-leiba-cotton-iana-5226bis-11 and reading that instead for the same
> reason).
>
> The Security Considerations section should say more about the limitations
> of this approach, e.g. the ability of an off-path attacker to correct for
> changes that would change a checksum with other changes that will restore
> it, which is my lazy précis of the no-doubt more succinct observation
> that Vixie made somewhere in this thread (or another thread near it).
>
> The primary point of this draft is to offer some degree of integrity
> protection for unsigned responses (since signed responses already have
> it); it might be useful to spell that out. If I receive a query with the
> CHECKSUM option which I support, but I know I'm going to return signed
> data (and DO=1 in the query) I might decide to pretend I don't implement
> CHECKSUM because it's not especially useful if I have RRSIGs to tell you
> about. Does the receiver of my response get to assume that I don't
> support CHECKSUM at all, and never ask for it again?

DO=1 does NOT indicate validation will be performed.  Additionally
referrals need CHECKSUM even with DO=1 and validation.  It makes it
harder to be sent down a broken path.

> If I send a query with the CHECKSUM option to a server (or through a
> middlebox) that doesn't handle unknown EDNS(0) option types correctly,
> and I hear no response, what should I do?

Complain to the zone owner and DNS operator.  If that doesn't work
complain to the parent zone to get the delegation REMOVED.  It's
time to get rid of the broken implementations.  Contact CERT and
issue a CVE for the product involved.  CVE were issued to NXDOMAIN
responses to AAAA queries and this is the same level of impact.

In the meantime try the next server for the zone and if the are all
broken return SERVFAIL to the client.

> If I receive something else
> unexpected (like a FORMERR), what should I do?

Switch back to plain DNS as FORMERR indicates lack of support for
EDNS and if the zone is signed return SERVFAIL when the validation
fails.  Named does this for DNS COOKIES.

We need to stick together and say "enough is enough" if you want
to deploy EDNS "DO IT PROPERLY" or not at all.  All the issues I've
seen in EDNS testing would take a developer less than 15 minutes
to fix.

> Not accommodating the
> errors of others might well be the right thing, here, but we know that
> end users don't care about technical correctness when "you are broken but
> my neighbour's ISP is fine" and hence there will be pressure to mitigate
> the failures of others in some way or other. Having different
> implementations fall back differently seems less than desirable.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Tue, 29 Sep 2015 15:37:41 +0100

Surely we should not be specifying SHA-1 in new protocols.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking, North Utsire: Easterly 4 or 5, increasing 6 at times. Slight or
moderate, but rough in southwest Viking. Showers later. Good, occasionally
poor later.

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 30 Sep 2015 08:02:29 +0530

Hi Joe

Thank you for this review. See comments below:

> >    reference, language and grammar.

The draft has been updated in the git repository towards this. It'll
show up in the next version.

> receives a DNS message with a CHECKSUM option that specifies an
> algorithm that is unknown by the receiver.

Similarly, the draft has been updated in the git repository towards
this. It'll show up in the next version.

> draft-leiba-cotton-iana-5226bis-11 and reading that instead for the
> same reason).

Similarly, the draft has been updated in the git repository towards
this. It'll show up in the next version. Thank you for citing these
references that helped in updating this section.

You can see a copy here:

http://users.isc.org/~muks/draft-muks-dnsop-dns-message-checksums.txt

> The Security Considerations section should say more about the
> limitations of this approach, e.g. the ability of an off-path attacker
> to correct for changes that would change a checksum with other changes
> that will restore it, which is my lazy précis of the no-doubt more
> succinct observation that Vixie made somewhere in this thread (or
> another thread near it).

I didn't understand this part. Candidate checksum algorithms will have
to be one-way cryptographic hash functions, and they will automatically
take care of this. The case that a cryptographic hash function may be
weakened in the future is obvious and understood. Perhaps you mean that
the security considerations section ought to state explicitly that this
case of reversing the hash function doesn't occur when using the
algorithms in appendix A?

> it); it might be useful to spell that out. If I receive a query with
> the CHECKSUM option which I support, but I know I'm going to return
> signed data (and DO=1 in the query) I might decide to pretend I don't
> implement CHECKSUM because it's not especially useful if I have RRSIGs
> to tell you about. Does the receiver of my response get to assume that
> I don't support CHECKSUM at all, and never ask for it again?
> 
> and I hear no response, what should I do? If I receive something else
> unexpected (like a FORMERR), what should I do? Not accommodating the
> end users don't care about technical correctness when "you are broken
> but my neighbour's ISP is fine" and hence there will be pressure to
> mitigate the failures of others in some way or other. Having different

Mark has sufficiently addressed this point in his reply. There is a
separate thread that mentions why use of DNSSEC doesn't imply that
CHECKSUM ought to be omitted.

		Mukund

---

From: "Joe Abley" <[email-masked]>
Date: Wed, 30 Sep 2015 08:28:21 -0400

On 29 Sep 2015, at 22:32, Mukund Sivaraman wrote:

> take care of this.

Any hash function is susceptible to collisions; this is surely a simple truism based on the mapping of an M-bit message to an N-bit digest where usually M >> N. If I can alter a message in such a way that the digest remains the same, I can defeat the checksum.

Surely the threat models here depend on the algorithm. I am no cryptographer, but it seems reasonable to mention the characteristics of the hash function that are important to minimise the risk of this kind of attack, especially when there are other motivations in choosing an algorithm (such as the speed at which it can be calculated) that might weaken the mechanism.

To choose an extreme example, it seems likely that choosing to calculate a parity bit would be much computationally cheaper than calculating a SHA-256 digest. However, a parity bit would not offer much protection against off-path attacks.

Joe

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 30 Sep 2015 18:52:52 +0530

Hi Joe

On Wed, Sep 30, 2015 at 08:28:21AM -0400, Joe Abley wrote:
> Surely the threat models here depend on the algorithm. I am no
> cryptographer, but it seems reasonable to mention the characteristics
> of the hash function that are important to minimise the risk of this
> kind of attack, especially when there are other motivations in
> choosing an algorithm (such as the speed at which it can be
> calculated) that might weaken the mechanism.

In the git repository, Appendix A now mentions the characteristics of
the hash function that are important to minimise the risk of this kind
of attack. A text version of the current copy can be viewed here:

		Mukund

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 30 Sep 2015 08:08:16 -0700

On 30 Sep 2015, at 5:28, Joe Abley wrote:

> Any hash function is susceptible to collisions; this is surely a 
> simple truism based on the mapping of an M-bit message to an N-bit 
> digest where usually M >> N.

It is true if M>N, and in practice may be true even if M=N.

> If I can alter a message in such a way that the digest remains the 
> same, I can defeat the checksum.

But now you switched from talking about collisions to talking about 
preimage attacks. Collision attacks are when you find two messages with 
the same hash *before issuing the messages*. SHA-1 (nor even MD5!) is so 
far not susceptible to preimage attacks.

> calculated) that might weaken the mechanism.

For this type of system, you want a hash or checksum function where 
finding collisions takes more than N attempts, and all of those attempts 
must be based on random guessing, not on some structure of the messages. 
N can be calibrated by the value of an attacker fooling you and the 
amount of time they have to create the collision. N=2^64 is probably 
sufficient for this attack because we still don't have a way to do 2^64 
guesses in a reasonable amount of time, and SHA-1 is still probably 
within that boundary. However, FNV (a non-cryptographic hash) has the 
same amount of collision protection but runs much faster.

> To choose an extreme example, it seems likely that choosing to 
> calculate a parity bit would be much computationally cheaper than 
> calculating a SHA-256 digest. However, a parity bit would not offer 
> much protection against off-path attacks.

Indeed. And this still calls into question whether trying to engineer a 
solution like this is a better idea than just using TCP.

--Paul Hoffman

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 30 Sep 2015 21:10:33 +0530

Hi Paul

On Wed, Sep 30, 2015 at 08:08:16AM -0700, Paul Hoffman wrote:
> >To choose an extreme example, it seems likely that choosing to calculate a
> >parity bit would be much computationally cheaper than calculating a
> >SHA-256 digest. However, a parity bit would not offer much protection
> >against off-path attacks.
> 

Joe is talking about the case when a simple parity bit algorithm is in
use where it is trivial to attack the scheme. I may not have followed
what you are referring to in your reply. Are you saying that when using
a cryptographic hash (such as even SHA-1), the CHECKSUM method is
vulnerable?

The topic of why TCP is not ready yet to be used exclusively has been
addressed in this thread, or another adjacent thread about CHECKSUM. We
aren't exclusively using it and until that switch is flipped which is
still far away, we need to protect UDP.

		Mukund