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

Pete Resnick <presnick@qti.qualcomm.com> Thu, 05 March 2015 06:51 UTC

Return-Path: <presnick@qti.qualcomm.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 84E641B29E6 for <ietf@ietfa.amsl.com>; Wed, 4 Mar 2015 22:51:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level:
X-Spam-Status: No, score=-7.011 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] 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 i2opxPn5CHk7 for <ietf@ietfa.amsl.com>; Wed, 4 Mar 2015 22:51:10 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D93D1B29E2 for <ietf@ietf.org>; Wed, 4 Mar 2015 22:51:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1425538271; x=1457074271; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=fzX0ZtACVyj/tdfCTwAPrD+FqCIeamR813DDv/cKdAw=; b=FatlNjUimHcyT6hSSMu+duo/zkH756tFg1VfbsPb9gXGFBB5bthwM4md M1JXuUaXQsnAuvDYxgu153ioSBRjTxe3iHZMOPjtsezLlK4SYy1I8DltU drI/GrQpyZ0Z9yPQfdwVyGqkxQFXJXDokhxc7c98dePyvpa3vSo1/xa/x M=;
X-IronPort-AV: E=McAfee;i="5600,1067,7730"; a="106383598"
Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Mar 2015 22:51:11 -0800
X-IronPort-AV: E=Sophos;i="5.11,345,1422950400"; d="scan'208";a="828713284"
Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Mar 2015 22:51:09 -0800
Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 4 Mar 2015 22:51:09 -0800
Message-ID: <54F7FCDB.7000208@qti.qualcomm.com>
Date: Thu, 5 Mar 2015 00:51:07 -0600
From: Pete Resnick <presnick@qti.qualcomm.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Viktor Dukhovni <ietf-dane@dukhovni.org>
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: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.80.80.8]
X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To NASANEXM01F.na.qualcomm.com (10.85.0.32)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/6Jai7NC-d5cTecekzLkT0QdzKpY>
Cc: Sam Hartman <hartmans-ietf@mit.edu>, ietf@ietf.org, =?ISO-8859-1?Q?F=E4ltstr=F6m_Patrik?= <paf@frobbit.se>
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:51:12 -0000

A specific text suggestion (even better if you and Sam were to agree on 
it) would be greatly appreciated.

pr

On 3/5/15 12: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.
>
>    

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478