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

Eliot Lear <lear@cisco.com> Thu, 05 March 2015 06:56 UTC

Return-Path: <lear@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2799D1B29E9 for <ietf@ietfa.amsl.com>; Wed, 4 Mar 2015 22:56:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFYgvgA15JAy for <ietf@ietfa.amsl.com>; Wed, 4 Mar 2015 22:56:13 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B8C1B29EB for <ietf@ietf.org>; Wed, 4 Mar 2015 22:56:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: A0CGBQA5/fdU/xbLJq1ag1SDZcQJAoFzAQEBAQEBfIQQAQEEI04HARALDgoJFgQHAgIJAwIBAgFFBgEMAQcBAYgrvHyaegEBAQEBAQEBAQEBAQEBAQEBAQEBAReLFIRuB4JogUMBBJFpgS6GO4EahViJOoNAI4F9NYE9PYJ0AQEB
X-IronPort-AV: E=Sophos;i="5.11,345,1422921600"; d="asc'?scan'208";a="371949121"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 05 Mar 2015 06:56:10 +0000
Received: from [10.61.107.12] (dhcp-10-61-107-12.cisco.com [10.61.107.12]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t256u9na026076; Thu, 5 Mar 2015 06:56:09 GMT
Message-ID: <54F7FE09.3030200@cisco.com>
Date: Thu, 05 Mar 2015 07:56:09 +0100
From: Eliot Lear <lear@cisco.com>
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 <ietf-dane@dukhovni.org>, Pete Resnick <presnick@qti.qualcomm.com>
Subject: Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
References: <tsl8ufoh9ko.fsf@mit.edu> <2DF7230C-D1D8-4B21-9003-B336108A38CB@vpnc.org> <20150224172649.GX1260@mournblade.imrryr.org> <tslvbircj0d.fsf@mit.edu> <0325DF3F-17F3-4400-BDEA-EDB5334BF35C@frobbit.se> <20150225180227.GT1260@mournblade.imrryr.org> <7AB921D35A7F9B23A53BD11A@JcK-HP8200.jck.com> <tslvbip8io6.fsf@mit.edu> <54F09A35.9060506@qti.qualcomm.com> <54F78650.6070503@qti.qualcomm.com> <20150305064513.GH1260@mournblade.imrryr.org>
In-Reply-To: <20150305064513.GH1260@mournblade.imrryr.org>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LH9ijgh5CukFLDmfJQxApb5opHTG4MWIw"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/hK211O7rX8IVcylkiuXPymFV4Mw>
X-Mailman-Approved-At: Thu, 05 Mar 2015 08:08:34 -0800
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, ietf@ietf.org, F?ltstr?m Patrik <paf@frobbit.se>, Mark Nottingham <mnot@mnot.net>, John C Klensin <john-ietf@jck.com>, Sam Hartman <hartmans-ietf@mit.edu>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2015 06:56:16 -0000

Victor,

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?

Eliot

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.
>