Re: [DNSOP] DNSSEC, additional special names & draft-chapin-additional-reserved-tlds-00.txt

Jim Reid <jim@rfc1035.com> Thu, 27 February 2014 12:15 UTC

Return-Path: <jim@rfc1035.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 14F151A026F for <dnsop@ietfa.amsl.com>; Thu, 27 Feb 2014 04:15:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.447
X-Spam-Level:
X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] 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 SigNEDYBt-Ck for <dnsop@ietfa.amsl.com>; Thu, 27 Feb 2014 04:15:35 -0800 (PST)
Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) by ietfa.amsl.com (Postfix) with ESMTP id B51931A0210 for <dnsop@ietf.org>; Thu, 27 Feb 2014 04:15:35 -0800 (PST)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 7A7D624212ED; Thu, 27 Feb 2014 12:15:33 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <20140227115518.D4628107FA73@rock.dv.isc.org>
Date: Thu, 27 Feb 2014 12:15:31 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <D27FE132-502B-46EE-8B55-CB71908BBEB8@rfc1035.com>
References: <20140129055438.2402.qmail@joyce.lan> <97E20887-2B9C-4EAD-826B-043306605F88@fl1ger.de> <54BE75D7-E70B-46AB-93C1-042E655BB5E7@apple.com> <D0AC0015-63C3-4C03-A8D0-888C435D2775@virtualized.org> <20140226100311.E73CA1069B39@rock.dv.isc.org> <8FEAF0FC-2AC3-4F39-9825-7068AAA6E40D@hopcount.ca> <6F605B46-51AD-4A21-BA3E-5723AA843EC6@virtualized.org> <20140227021436.E957210702F7@rock.dv.isc.org> <7E284F2F-1A99-4E57-B7BD-46129AEDDD04@virtualized.org> <20140227074249.2972F107D273@rock.dv.isc.org> <B67B8708-66D9-4372-B3E4-58FBC3297E9D@rfc1035.com> <20140227115518.D4628107FA73@rock.dv.isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.1510)
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/c-KQGdHHUpCT5KSQgnrEhv8-uSY
Cc: DNSOP WG <dnsop@ietf.org>, David Conrad <drc@virtualized.org>
Subject: Re: [DNSOP] DNSSEC, additional special names & draft-chapin-additional-reserved-tlds-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: <http://www.ietf.org/mail-archive/web/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, 27 Feb 2014 12:15:37 -0000

On 27 Feb 2014, at 11:55, Mark Andrews <marka@isc.org>; wrote:

> 
> In message <B67B8708-66D9-4372-B3E4-58FBC3297E9D@rfc1035.com>;, Jim Reid writes:
>> On 27 Feb 2014, at 07:42, Mark Andrews <marka@isc.org>; wrote:
>> 
>>> DNSSEC will eventually be on by default and squatting like this will
>> have negative consequences.
>> 
>> Er, no. Vendors who pluck domain names out of the ether and use them in
>> their products will by definition not have the DNS clue required for
>> deploying a viable DNSSEC. Besides, in the case of CPE, they won't even
>> *need* DNSSEC because the offending domain names (router.home or
>> whatever) get looked up on the internal net. Most likely those names will
>> be used by web browsers that do not have a validating resolver and are
>> already relying on the CPE for DNS. Those lookups will almost never go to
>> the outside, far less validate a signed referral for .whatever from the
>> root.
> 
> And the moment you have a validating brower / app they *will* break.

And this is a problem because... ?

I doubt there will ever be validating browsers/apps for accessing CPE from the inside. They have no need for DNSSEC because everything's on the local net. But let's assume they do. The Netgear app could have a TA for .netgear (say) embedded in it. A more likely scenario is the software hard-wires a locally scoped IP address to the device and doesn't bother with DNS at all. Most CPE is already doing that as a fall-back in case local (unsigned) DNS is broken.

> reserved indefinitely != insecurely delegated

Not delegated at all == ???

> 10.in-addr.arpa is insecurely delegated deliberately to prevent DNSSEC
> breakages.

Sure. But that's in a part of the name space where end client behaviour is known, stable and predictable.

Are you suggesting IANA has to insert provably insecure delegations for every possible string that someone, somewhere might be informally using as a TLD? Good luck with that.