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

Sam Hartman <hartmans-ietf@mit.edu> Thu, 05 March 2015 16:45 UTC

Return-Path: <hartmans@mit.edu>
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 E62AA1A1B95 for <ietf@ietfa.amsl.com>; Thu, 5 Mar 2015 08:45:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no
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 xWSjFOyAG2Yi for <ietf@ietfa.amsl.com>; Thu, 5 Mar 2015 08:45:03 -0800 (PST)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623691A1BC3 for <ietf@ietf.org>; Thu, 5 Mar 2015 08:36:45 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id EC5FA20644; Thu, 5 Mar 2015 11:35:20 -0500 (EST)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVAvmWoT4z6p; Thu, 5 Mar 2015 11:35:20 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Thu, 5 Mar 2015 11:35:20 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1D304813FF; Thu, 5 Mar 2015 11:36:12 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: John C Klensin <john-ietf@jck.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> <54F7FE09.3030200@cisco.com> <7111545C27DE9021135BE185@JcK-HP8200.jck.com>
Date: Thu, 05 Mar 2015 11:36:12 -0500
In-Reply-To: <7111545C27DE9021135BE185@JcK-HP8200.jck.com> (John C. Klensin's message of "Thu, 05 Mar 2015 11:25:19 -0500")
Message-ID: <tslegp3o0zn.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/zEAwzqKW-yzwsSeT85qSYRVaCns>
X-Mailman-Approved-At: Fri, 06 Mar 2015 08:06:28 -0800
Cc: Phillip Hallam-Baker <phill@hallambaker.com>, ietf@ietf.org, Pete Resnick <presnick@qti.qualcomm.com>, F?ltstr?m Patrik <paf@frobbit.se>, Mark Nottingham <mnot@mnot.net>, 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 16:45:05 -0000

>>>>> "John" == John C Klensin <john-ietf@jck.com> writes:

    John> If anything, the text now says too much because introductory
    John> statements like "The basic mechanism for successful use of URI
    John> works..." strongly imply that use of, and reliance on, DNSSEC
    John> is the only way to accomplish successful (and safe) use.  The
    John> current Security Considerations section could be equated to an
    John> Applicability Statement that said "unless DNSSEC is used, and
    John> used as specified in this document, use of the URI RR is NOT
    John> RECOMMENDED".  I don't think that is either intended or
    John> justified.

I do think an applicability statement that says this RR is inappropriate
for situations where authentication of the accessed resource is desired
and DNSSec is not used.  I think that's justified and hoped something
like that was intended by section 7.
I agree that there are uses where you don't care about the
authentication of the accessed resource where DNSSec is not required.