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

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 05 March 2015 07:14 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 312E01B29FA for <ietf@ietfa.amsl.com>; Wed, 4 Mar 2015 23:14:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 1kFQ9TD_hy3s for <ietf@ietfa.amsl.com>; Wed, 4 Mar 2015 23:14:10 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C05381B29F9 for <ietf@ietf.org>; Wed, 4 Mar 2015 23:14:10 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 3E715282FCC; Thu, 5 Mar 2015 07:14:09 +0000 (UTC)
Date: Thu, 5 Mar 2015 07:14:09 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: ietf@ietf.org
Subject: Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard
Message-ID: <20150305071409.GK1260@mournblade.imrryr.org>
References: <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> <54F7FE09.3030200@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54F7FE09.3030200@cisco.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/RW6y9aZHv-xLMO2YhoAErdhjWM8>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: ietf@ietf.org
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 07:14:12 -0000

On Thu, Mar 05, 2015 at 07:56:09AM +0100, Eliot Lear wrote:
> 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?

I don't see a need to explore the details in this draft, rather it
just needs to avoid claiming equivalence.  Just don't pretend the
issue is not there.  

So for me it would be enough to note that DNSSEC introduces a new
trust model than application designers need to consider when the
URI DNS record is introduced into application designs.

If that's good enough for Sam too, then perhaps he or I can write
a sentence or two saying essentially that to replace the IMHO overly
strong claim that DNSSEC indirection is essentially the same as
HTTP redirects.

-- 
	Viktor.