Re: [DNSOP] Updated cheese-shop: cost/benefit analysis, please?

Ted Lemon <Ted.Lemon@nominum.com> Thu, 25 February 2016 18:32 UTC

Return-Path: <Ted.Lemon@nominum.com>
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 7ED901B309B for <dnsop@ietfa.amsl.com>; Thu, 25 Feb 2016 10:32:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] 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 aTFViX4u__fI for <dnsop@ietfa.amsl.com>; Thu, 25 Feb 2016 10:32:38 -0800 (PST)
Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D012A1B3093 for <dnsop@ietf.org>; Thu, 25 Feb 2016 10:32:38 -0800 (PST)
Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id AD3CE740048; Thu, 25 Feb 2016 18:32:38 +0000 (UTC)
Received: from mbx-03.WIN.NOMINUM.COM ([169.254.4.19]) by CAS-04.WIN.NOMINUM.COM ([64.89.235.67]) with mapi id 14.03.0224.002; Thu, 25 Feb 2016 10:32:33 -0800
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Warren Kumari <warren@kumari.net>, dnsop <dnsop@ietf.org>
Thread-Topic: [DNSOP] Updated cheese-shop: cost/benefit analysis, please?
Thread-Index: AQHRb/j5Ya1170FEcEyS4Te3SAtViZ89FUJJ
Date: Thu, 25 Feb 2016 18:32:32 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B630797A3159F@mbx-03.WIN.NOMINUM.COM>
References: <8D23D4052ABE7A4490E77B1A012B630797A3154D@mbx-03.WIN.NOMINUM.COM>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630797A3154D@mbx-03.WIN.NOMINUM.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [71.233.41.235]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/UuS-8VeElbup0bqh23G4s5QEy4c>
Subject: Re: [DNSOP] Updated cheese-shop: cost/benefit analysis, please?
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: Thu, 25 Feb 2016 18:32:40 -0000

An additional point about this: the case where the cheese shop solution works is really the case where large service provider DNS caches do the aggressive caching.   In this case we can get the same benefit without DNSSEC by simply keeping a complete copy of the root zone at the DNS cache.   This adds a small operational complexity in keeping that copy up to date, but eliminates the implementation complexity of the cheese shop or fullly aggressive NSEC cache.

So why isn't that a better way to address this problem?
________________________________________
From: DNSOP [dnsop-bounces@ietf.org] on behalf of Ted Lemon [Ted.Lemon@nominum.com]
Sent: Thursday, February 25, 2016 13:18
To: Warren Kumari; dnsop
Subject: Re: [DNSOP] Updated cheese-shop: cost/benefit analysis, please?

I'm sorry to be a sticky wicket here, but I have to ask: have you thought about what a guaranteed-correct implementation of this would look like?   I think you need to actually do that analysis before we proceed with this.   As best I understand it, getting this right is not trivial, and getting it wrong would be harmful.   While it clearly would help in the context of widespread adoption of DNSSEC, I'm not convinced that the security risk of the added complexity would be compensated for by an actual reduction in woe at the root.

I would like to see the WG seriously analyze this problem before considering proceeding with either this proposal or the other.
________________________________________
From: DNSOP [dnsop-bounces@ietf.org] on behalf of Warren Kumari [warren@kumari.net]
Sent: Wednesday, February 24, 2016 23:58
To: dnsop
Subject: [DNSOP] Updated cheese-shop.

Dear DNSOP,

We have recently updated "Believing NSEC records in the DNS root" (https://tools.ietf.org/html/draft-wkumari-dnsop-cheese-shop-01).

This incorporates some comments, but also does a better job of explaining the technique, what the benefits are, and why we are only handling the special case of the root zone.
We believe that, in this limited use-case the suggestions in Section 4.5 of RFC4035 are not as relevant. We also believe that the NSEC case (and no wildcards :-)) is simpler to solve than the NSEC3 case.

For these reasons we think that it is worth pursuing this in parallel with Fujiwara-san's "Aggressive use of NSEC/NSEC3" document.
cheese-shop does not conflict with "Aggressive use...",  rather it complements it, and can demonstrate the technique (in this restricted use case).

We welcome any feedback, including tomatoes, howls of derisive laughter, etc.

W

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop