Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

Eliot Lear <> Thu, 05 March 2015 06:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2799D1B29E9 for <>; Wed, 4 Mar 2015 22:56:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lFYgvgA15JAy for <>; Wed, 4 Mar 2015 22:56:13 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77B8C1B29EB for <>; Wed, 4 Mar 2015 22:56:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3898; q=dns/txt; s=iport; t=1425538572; x=1426748172; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=z72zsXWOwB8435dqCwp4bLYPkt9i2++vvacSRWbJbvc=; b=iuKkkKUwcgnZpHmnIUEm4ueNZ2XFGuQY6akqBKZSaSMgQc4EM37GaEAf HDDLYSekRzl7c+uQjKzJ4j6/4DilihyJAD7PfSI78fL8EDR2p8EYzXtQi zkAQfnYQPAUW8E31Rr+Mv8QNMDGJcJLFhjnNw4S9N1VSPo5a0A/M+HI6l I=;
X-Files: signature.asc : 486
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.11,345,1422921600"; d="asc'?scan'208";a="371949121"
Received: from (HELO ([]) by with ESMTP; 05 Mar 2015 06:56:10 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id t256u9na026076; Thu, 5 Mar 2015 06:56:09 GMT
Message-ID: <>
Date: Thu, 05 Mar 2015 07:56:09 +0100
From: Eliot Lear <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Viktor Dukhovni <>, Pete Resnick <>
Subject: Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LH9ijgh5CukFLDmfJQxApb5opHTG4MWIw"
Archived-At: <>
X-Mailman-Approved-At: Thu, 05 Mar 2015 08:08:34 -0800
Cc: Phillip Hallam-Baker <>,, F?ltstr?m Patrik <>, Mark Nottingham <>, John C Klensin <>, Sam Hartman <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Mar 2015 06:56:16 -0000


A simple way to address the concern that Sam raised is to note that
DNSSEC's trust model is largely binary, and not subject to alternative
trust anchors.  That is- parent zone administrator's keys may either be
trusted or not.  On the other hand, I don't know that this is the draft
to take on that issue.  It's a fundamental difference between the two
models and there are pluses and minuses to each, and it's perhaps worth
exploring, but in this draft?


On 3/5/15 7:45 AM, Viktor Dukhovni wrote:
> On Wed, Mar 04, 2015 at 04:25:20PM -0600, Pete Resnick wrote:
>>> I'm going to ask Patrik to publish a revised ID at this point, which I
>>> expect to see in the next couple of days.
>> The new version of the document (-12) is out, announcement attached. It is
>> now Informational, it removes the discussion of flag "D" for NAPTR, and adds
>> a bit of discussion to security considerations. I would appreciate folks
>> giving it a sniff and making sure it addresses your earlier concerns. If so,
>> I'll go ahead and ballot it for the 12-March IESG telechat.
> I think this still fails to acknowledge Sam Hartman's concerns
> about the change in the security model from (often with TLS)
> application configured trust anchors that may be specific to the
> expected peer, to likely the ICANN DNSSEC root trust-anchor, or
> perhaps an enterprise DNS trust-anchor for an internal domain.
> While such a change in the trust model may well be applicable,
> there remains in the draft a claim that indirection through DNSSEC
> is fundamentally not different from indirection through a TLS
> authenticated HTTP redirect.  That claim is likely too bold.  Future
> users of this RR need to consider the issues more carefully.
> * DNSSEC is often stronger than today's Web PKI DV certs.
> * However, with the traditional PKI it is far easier to
>   not trust any of the usual suspects and built direct
>   peer to peer trust.
> * With DNSSEC the most specific one can be is in some cases have
>   a local trust-anchor for the zone apex of the service domain,
>   ( I'm involved in an internal DNSSEC deployment with some secure
>   internal zones with explicit local trust-anchor settings. )
> * More broadly however there's just the ICANN root, and perhaps
>   some day the ability to use RFC 5011 to track zsk rollovers 
>   of any TLDs that commit to implement the requisite key management
>   discipline.  Going beyond that to bilateral trust-anchors between
>   business partner organizations is rather exotic.
> * All the while various non-browser B2B applications employ explicit
>   destination-specific trust-anchors that perhaps should not be
>   subordinate to the ICANN root or gTLDs.
> So various problem spaces are better served by the Web PKI, DNSSEC
> PKI or just bilaterally managed trust anchors, and these are not
> simply interchangeable.