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

Mukund Sivaraman <muks@isc.org> Tue, 29 September 2015 04:53 UTC

Return-Path: <muks@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 7076D1A038D for <dnsop@ietfa.amsl.com>; Mon, 28 Sep 2015 21:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.465
X-Spam-Level:
X-Spam-Status: No, score=-0.465 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=0.77, SPF_SOFTFAIL=0.665] autolearn=no
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 oZ-pGNv7yT0R for <dnsop@ietfa.amsl.com>; Mon, 28 Sep 2015 21:53:55 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA1A1A039C for <dnsop@ietf.org>; Mon, 28 Sep 2015 21:53:55 -0700 (PDT)
Received: from jurassic.l0.malgudi.org (unknown [115.118.74.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 2E0992BA0A7E; Tue, 29 Sep 2015 04:53:50 +0000 (GMT)
Date: Tue, 29 Sep 2015 10:23:46 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Paul Wouters <paul@nohats.ca>
Message-ID: <20150929045345.GC4513@jurassic.l0.malgudi.org>
References: <20150926191009.28433.58915.idtracker@ietfa.amsl.com> <20150926191551.GA32562@jurassic.l0.malgudi.org> <20150928173028.GA2328@mycre.ws> <20150928173255.GA23429@jurassic.l0.malgudi.org> <20150928182004.GA3197@mycre.ws> <56098631.4060607@redbarn.org> <alpine.LFD.2.20.1509281435590.5153@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="uXxzq0nDebZQVNAZ"
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.20.1509281435590.5153@bofh.nohats.ca>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/Ra01xaLr9aCVyENl7bxQstNL_mY>
Cc: dnsop <dnsop@ietf.org>, Paul Vixie <paul@redbarn.org>
Subject: Re: [DNSOP] New Version Notification for draft-muks-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 04:53:56 -0000

Hi Paul

On Mon, Sep 28, 2015 at 02:36:25PM -0400, Paul Wouters wrote:
> On Mon, 28 Sep 2015, Paul Vixie wrote:
> 
> >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.
> 
> It's called DNSSEC.

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