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

Mark Andrews <marka@isc.org> Tue, 29 September 2015 02:17 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36D11B2D67 for <dnsop@ietfa.amsl.com>; Mon, 28 Sep 2015 19:17:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3fqxvyordoq for <dnsop@ietfa.amsl.com>; Mon, 28 Sep 2015 19:17:12 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57BCC1B2D64 for <dnsop@ietf.org>; Mon, 28 Sep 2015 19:17:12 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 256493493BC; Tue, 29 Sep 2015 02:17:10 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 7C93816003F; Tue, 29 Sep 2015 02:18:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 68D3E160051; Tue, 29 Sep 2015 02:18:47 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AZNgsUBg_QsS; Tue, 29 Sep 2015 02:18:47 +0000 (UTC)
Received: from rock.dv.isc.org (c122-106-161-187.carlnfd1.nsw.optusnet.com.au [122.106.161.187]) by zmx1.isc.org (Postfix) with ESMTPSA id D9E9B16003F; Tue, 29 Sep 2015 02:18:46 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 3097738BDE8D; Tue, 29 Sep 2015 12:17:07 +1000 (EST)
To: Joe Abley <jabley@hopcount.ca>
From: Mark Andrews <marka@isc.org>
References: <20150928155157.GB19077@jurassic.l0.malgudi.org> <BB4FDC1E-4FC7-4583-8314-5D3BBCB3531A@hopcount.ca>
In-reply-to: Your message of "Mon, 28 Sep 2015 19:53:10 -0400." <BB4FDC1E-4FC7-4583-8314-5D3BBCB3531A@hopcount.ca>
Date: Tue, 29 Sep 2015 12:17:07 +1000
Message-Id: <20150929021707.3097738BDE8D@rock.dv.isc.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/VmDVX8scr7y5ZQdswDTIT8owYHk>
Cc: dnsop@ietf.org, Mukund Sivaraman <muks@isc.org>
Subject: Re: [DNSOP] New Version Notification for draft-muks-dnsop-dns-message-checksums-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2015 02:17:18 -0000

In message <BB4FDC1E-4FC7-4583-8314-5D3BBCB3531A@hopcount.ca>, "Joe Abley" writ
es:
>
> On 28 Sep 2015, at 11:51, Mukund Sivaraman wrote:
>
> > 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.
>
>                     +-------+-------+-----------------+
>                     | 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?

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.

> Joe
>

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org