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

Mukund Sivaraman <muks@isc.org> Tue, 29 September 2015 05:51 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 544F71A1A9B for <dnsop@ietfa.amsl.com>; Mon, 28 Sep 2015 22:51:22 -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 3sxgbnhOfgLh for <dnsop@ietfa.amsl.com>; Mon, 28 Sep 2015 22:51:21 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 009241A1A9A for <dnsop@ietf.org>; Mon, 28 Sep 2015 22:51:21 -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 70D7A2BA0BCB; Tue, 29 Sep 2015 05:51:17 +0000 (GMT)
Date: Tue, 29 Sep 2015 11:21:12 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Paul Wouters <paul@nohats.ca>
Message-ID: <20150929055112.GA5779@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> <20150929045345.GC4513@jurassic.l0.malgudi.org> <alpine.LFD.2.20.1509290129380.28073@bofh.nohats.ca>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4"
Content-Disposition: inline
In-Reply-To: <alpine.LFD.2.20.1509290129380.28073@bofh.nohats.ca>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/PkfaIkeyC8q1g6rzTPqk_lWxISY>
Cc: dnsop <dnsop@ietf.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 05:51:22 -0000

Hi Paul

On Tue, Sep 29, 2015 at 01:33:57AM -0400, Paul Wouters wrote:
> 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? :)

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.

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

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.

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

		Mukund