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
- Re: [DNSOP] New Version Notification for draft-mu… Mukund Sivaraman
- Re: [DNSOP] New Version Notification for draft-mu… Mukund Sivaraman
- Re: [DNSOP] New Version Notification for draft-mu… Mukund Sivaraman
- Re: [DNSOP] New Version Notification for draft-mu… Paul Wouters
- Re: [DNSOP] New Version Notification for draft-mu… Mukund Sivaraman
- Re: [DNSOP] New Version Notification for draft-mu… Paul Vixie
- Re: [DNSOP] New Version Notification for draft-mu… Robert Edmonds
- Re: [DNSOP] New Version Notification for draft-mu… Mukund Sivaraman
- Re: [DNSOP] New Version Notification for draft-mu… Evan Hunt
- Re: [DNSOP] New Version Notification for draft-mu… Robert Edmonds
- Re: [DNSOP] New Version Notification for draft-mu… Paul Vixie
- Re: [DNSOP] New Version Notification for draft-mu… Paul Hoffman
- Re: [DNSOP] New Version Notification for draft-mu… Paul Wouters
- Re: [DNSOP] New Version Notification for draft-mu… Mukund Sivaraman
- Re: [DNSOP] New Version Notification for draft-mu… Mukund Sivaraman
- Re: [DNSOP] New Version Notification for draft-mu… Paul Wouters
- Re: [DNSOP] New Version Notification for draft-mu… Mukund Sivaraman
- Re: [DNSOP] New Version Notification for draft-mu… Davey Song
- Re: [DNSOP] New Version Notification for draft-mu… Ólafur Guðmundsson