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

Ted Lemon <Ted.Lemon@nominum.com> Thu, 25 February 2016 18:18 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 1B1ED1B2FCE for <dnsop@ietfa.amsl.com>; Thu, 25 Feb 2016 10:18:59 -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 MKVp_Dr5cpa5 for <dnsop@ietfa.amsl.com>; Thu, 25 Feb 2016 10:18:57 -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 5733C1B2F95 for <dnsop@ietf.org>; Thu, 25 Feb 2016 10:18:57 -0800 (PST)
Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (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 04F7F740058; Thu, 25 Feb 2016 18:18:57 +0000 (UTC)
Received: from mbx-03.WIN.NOMINUM.COM ([169.254.4.19]) by CAS-03.WIN.NOMINUM.COM ([64.89.235.66]) with mapi id 14.03.0224.002; Thu, 25 Feb 2016 10:18:50 -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/j5Ya1170FEcEyS4Te3SAtViQ==
Date: Thu, 25 Feb 2016 18:18:49 +0000
Message-ID: <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/5TusdYuefgWf7Ki7P9DSQqqDgvg>
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:18:59 -0000

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