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> Wed, 25 February 2015 18:56 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 4B5521A1AA2 for <ietf@ietfa.amsl.com>; Wed, 25 Feb 2015 10:56:38 -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 nsu49hCgw7JF for <ietf@ietfa.amsl.com>; Wed, 25 Feb 2015 10:56:36 -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 B05311A1A4B for <ietf@ietf.org>; Wed, 25 Feb 2015 10:56:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 4F6EE20216 for <ietf@ietf.org>; Wed, 25 Feb 2015 13:56:01 -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 9XgeaVvwVEcf for <ietf@ietf.org>; Wed, 25 Feb 2015 13:56:00 -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 for <ietf@ietf.org>; Wed, 25 Feb 2015 13:56:00 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 56DCF80435; Wed, 25 Feb 2015 13:56:33 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
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
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>
Date: Wed, 25 Feb 2015 13:56:33 -0500
In-Reply-To: <20150225180227.GT1260@mournblade.imrryr.org> (Viktor Dukhovni's message of "Wed, 25 Feb 2015 18:02:28 +0000")
Message-ID: <tsla901akgu.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/zyLJ8RAdGUrs2iIB7CriOYNhjT8>
X-Mailman-Approved-At: Thu, 26 Feb 2015 08:10:27 -0800
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: Wed, 25 Feb 2015 18:56:38 -0000

>>>>> "Viktor" == Viktor Dukhovni <ietf-dane@dukhovni.org> writes:

    Viktor> You might wonder why I of all people should be making a fuss
    Viktor> about using DNS for TLS security.  After all, I'm
    Viktor> co-authoring two DANE documents and described DANE as a
    Viktor> candidate mechanism for opportunistic use of authentication
    Viktor> in the Opportunistic Security [RFC7435] document.

    Viktor> The reason is absolutely not that I am opposed to designs
    Viktor> that employ and trust DNSSEC to enable TLS reference
    Viktor> identifier indirection.  I support the use of such designs.
    Viktor> Rather, it seems that the URI draft glosses over the
    Viktor> implementation details and implications much too casually.
    Viktor> This is a major change from current practice, and I think
    Viktor> should be acknowledged as such and explored in more detail.

I too support designs like this that use DNSSec to support TLS reference
identifier indirection as an approach that is appropriate for a
significant number of deployments.
So, I do think we should have standards in this space, but I think we
need to explore the implications of this major change.

I also want appropriate policy controls in place.  This is great for
some deployments and would significantly reduce the security of other
deployments.  So, in terms of policy, I'd want us to explore what sort
of policy we need to enable and also to find credible mechanisms for the
policy we decide we need.  One of the simplest ways to apply policy is
to do so at the protocol/application level.  For example we might decide
that mechanisms like the URI RR are appropriate when we're using large
trust anchor sets like the web PKI, but not when we're using application
or protocol-specific trust anchor sets.
That sort of policy is easy because you can codify it in standards
documents and implementations.

Where we decide that the policy is deployment specific, it it may get
much more complicated.

Still, I think we need to have at least the general version of that
discussion prior to putting a mechanism like this on the standards
track.

Earlier, I said that I thought it was premature to have a last-call on
this draft and Pete questioned me about that.  What I mean is that I
think it is premature to approve this draft without an additional last
call.  Even if we make minor textual changes, the implications are
significant enough that I think we should have a full re-review with a
better understanding of the security implications.  I didn't get that
when I approached the existing last call.
I agree with Pete that drawing out this round of comments was very
useful.

I disagree that SRV or MX introduces similar complexity into standards.