[dnsext] On dying WGs, bugs and incompatibilities, was Re: Clarifying a few points in Re: Update to RFC 5155. Maybe?

Edward Lewis <ed.lewis@neustar.biz> Fri, 21 December 2012 19:23 UTC

Return-Path: <ed.lewis@neustar.biz>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7DD21F845D for <dnsext@ietfa.amsl.com>; Fri, 21 Dec 2012 11:23:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.929
X-Spam-Level:
X-Spam-Status: No, score=-100.929 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUAm-091Bntb for <dnsext@ietfa.amsl.com>; Fri, 21 Dec 2012 11:23:44 -0800 (PST)
Received: from eastrmfepo203.cox.net (eastrmfepo203.cox.net [68.230.241.218]) by ietfa.amsl.com (Postfix) with ESMTP id 01AEE21F8586 for <dnsext@ietf.org>; Fri, 21 Dec 2012 11:23:43 -0800 (PST)
Received: from eastrmimpo210 ([68.230.241.225]) by eastrmfepo203.cox.net (InterMail vM.8.01.04.00 201-2260-137-20101110) with ESMTP id <20121221192340.WJTI29905.eastrmfepo203.cox.net@eastrmimpo210> for <dnsext@ietf.org>; Fri, 21 Dec 2012 14:23:40 -0500
Received: from [127.0.0.1] ([68.98.141.167]) by eastrmimpo210 with cox id eKPf1k00T3cuADQ01KPgUT; Fri, 21 Dec 2012 14:23:40 -0500
X-CT-Class: Clean
X-CT-Score: 0.00
X-CT-RefID: str=0001.0A020209.50D4B73C.0106,ss=1,re=0.000,fgs=0
X-CT-Spam: 0
X-Authority-Analysis: v=2.0 cv=R/2B6KtX c=1 sm=1 a=d1qrA6Qzssd1VjKW2xnq3A==:17 a=vEb-JLZKi4kA:10 a=hGBaWAWWAAAA:8 a=qVfqAfe6hbUA:10 a=51_ngRED_UWKosc57IAA:9 a=CjuIK1q_8ugA:10 a=9k6G2--EmesA:10 a=UGEwT_Dh9V-IVJQW:21 a=o2_0XHrNTYizWFQe:21 a=gOEtbwst4t-8DKlUusMA:9 a=_W_S_7VecoQA:10 a=W2p7w_BTirvtfC1R:21 a=d1qrA6Qzssd1VjKW2xnq3A==:117
X-CM-Score: 0.00
Authentication-Results: cox.net; none
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_50AF24FA-A0A6-4656-A8EB-EB90CFB5F7B3"
From: Edward Lewis <ed.lewis@neustar.biz>
X-Priority: 3
In-Reply-To: <3FF91D04B500497C84CF362E3967FE40@LENOVO47E041CF>
Date: Fri, 21 Dec 2012 14:23:39 -0500
Message-Id: <F1218589-9178-40C1-876C-364E2240E83D@neustar.biz>
References: <20121206211100.14488.62562.idtracker@ietfa.amsl.com><82AEB125-F110-40A1-A527-F18BB567EBE4@neustar.biz><50CAF418.5060304@nlnetlabs.nl><6B0BDF89-EDEB-44AF-83E8-6EDC599B3DAD@neustar.biz><33CB3A55-89FE-4ABA-A9F8-0C537FADC15A@neustar.biz><20121217203354.0B2E62D200AD@drugs.dv.isc.org><95C76953-2D89-4EBC-86D7-BDBBE0379041@neustar.biz> <5DE8AF7F-92B3-48C8-8F5D-6800C4ED4B63@neustar.biz> <3FF91D04B500497C84CF362E3967FE40@LENOVO47E041CF>
To: dnsext mailing list <dnsext@ietf.org>
X-Mailer: Apple Mail (2.1283)
Cc: Edward Lewis <ed.lewis@neustar.biz>
Subject: [dnsext] On dying WGs, bugs and incompatibilities, was Re: Clarifying a few points in Re: Update to RFC 5155. Maybe?
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Dec 2012 19:23:45 -0000

On Dec 21, 2012, at 1:32, Jiankang YAO wrote:
> which working group you will pitch in since the dnsext will soon close down?


First, the process question.  The plan to handle the situation here is to submit an errata against RFC 5155.  Instead of just doing so outright, I wanted to get community feedback on what the right approach is.  This nugget of work is itself a "bug fix" against a completed RFC, something that is permanent - unlike WGs which my design are supposed to come and go.

The "bug" or "incompatibility" of wildcards and opt-out has been long known.  But I don't think it's a major problem.  On paper it looks like someone can spoof in a delegation that blocks a wildcard synthesis.  But in operations, the zones that would need to use opt-out are not zones that (generally) use wildcards.  You could, easily, but, in reality, no one does - outside of testing perhaps.

A malicious person could steal a credit card to pay for a stolen identity to register a name to host malware OR cache poison a bunch of servers via a Kaminsky-style attack to insert a name to host malware.  I'm not trained to think like a black-hat, but is seems to me that the former is a lot more common and promises more payoff.

As far as the notion that opt-out would be used in zone where the names are numbers - enum or reverse - opt-out isn't all that useful.  Besides the limited "guess space" in the number zones, operational use of enum has greater issues with confidentiality of the zones.  (I.e., bigger fish to fry.)

But ... What I'll repeat here is that I think that omitting ENTs from the NSEC3 chain is a optimization that gains little and costs a lot.  A lot in debugging time, a lot in spec writing time (because of having to expand the rules in the signer, server, and validator) and coding time.  Even if the spec and coding are sunk costs a this point, debugging and other maintenance costs lie in the future.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.