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, 26 February 2015 03:18 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 DB82B1A8727 for <ietf@ietfa.amsl.com>; Wed, 25 Feb 2015 19:18:24 -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 zEiKImEjKcwx for <ietf@ietfa.amsl.com>; Wed, 25 Feb 2015 19:18:23 -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 5CD3F1A1B80 for <ietf@ietf.org>; Wed, 25 Feb 2015 19:18:22 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id BBCF320216; Wed, 25 Feb 2015 22:17:45 -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 YlRQORXW3zNc; Wed, 25 Feb 2015 22:17:44 -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; Wed, 25 Feb 2015 22:17:44 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 050E280489; Wed, 25 Feb 2015 22:18:18 -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: <54C9DA42.5040901@cisco.com> <9EB44D8A-278B-42FC-A542-1C182AD43128@netnod.se> <A74A30F4D1214630918FD4CA@JcK-HP8200.jck.com> <20150223153757.GI1260@mournblade.imrryr.org> <20150223155241.GJ1260@mournblade.imrryr.org> <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>
Date: Wed, 25 Feb 2015 22:18:17 -0500
In-Reply-To: <7AB921D35A7F9B23A53BD11A@JcK-HP8200.jck.com> (John C. Klensin's message of "Wed, 25 Feb 2015 15:32:23 -0500")
Message-ID: <tslvbip8io6.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/yXNH11-xlvYtrJFv9ARB9MP4gxs>
X-Mailman-Approved-At: Thu, 26 Feb 2015 08:10:27 -0800
Cc: ietf@ietf.org
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, 26 Feb 2015 03:18:25 -0000

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

    John> I think the rest is a bit of a judgment call.  While I'd be
    John> happy to see a comprehensive document that would address all
    John> of those issues, I would also like to get a good description
    John> of the RRTYPE published somewhere soon, ideally a couple of
    John> years ago.  It seems to me that making a complete analysis of
    John> security alternatives, or a complete analysis of the URI
    John> situation as it relates to this RRTYPE, much less both are
    John> likely to be a _lot_ of effort and that, if we want to get the
    John> document published, what should be done should probably be
    John> confined to explicitly noting the issues, e.g., that any
    John> indirection through the DNS raises security issues that need
    John> careful understanding and for which there is no magic bullet.

I'm happy with an informational document that does the above and claims
only to describe the existing RR type.
I'm not happy with a standards-track document that fails to cover the
security issues in significantly better detail.