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> Fri, 27 February 2015 18:39 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 9E7B91A1B47 for <ietf@ietfa.amsl.com>; Fri, 27 Feb 2015 10:39:50 -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 Yc-344y-mRwk for <ietf@ietfa.amsl.com>; Fri, 27 Feb 2015 10:39:49 -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 8977C1A1B15 for <ietf@ietf.org>; Fri, 27 Feb 2015 10:39:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 5E4252055E for <ietf@ietf.org>; Fri, 27 Feb 2015 13:39:09 -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 lwIKGU2yrXWU for <ietf@ietf.org>; Fri, 27 Feb 2015 13:39:08 -0500 (EST)
Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.106]) (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>; Fri, 27 Feb 2015 13:39:08 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6551D87131; Fri, 27 Feb 2015 13:39:47 -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: <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> <CAK3OfOjTs84ckEXanQrtQZU-ei-o5C0wRLQq4inQ8mb5cKXAow@mail.gmail.com> <20150227182707.GW1260@mournblade.imrryr.org>
Date: Fri, 27 Feb 2015 13:39:47 -0500
In-Reply-To: <20150227182707.GW1260@mournblade.imrryr.org> (Viktor Dukhovni's message of "Fri, 27 Feb 2015 18:27:07 +0000")
Message-ID: <tslh9u742rw.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/LOLq2Uan4oH38MOp5WQUg-3UiKk>
X-Mailman-Approved-At: Mon, 02 Mar 2015 07:11:37 -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: Fri, 27 Feb 2015 18:39:50 -0000

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

    Viktor> On Fri, Feb 27, 2015 at 10:46:12AM -0600, Nico Williams wrote:
    >> I would much prefer a Standards-Track document that says to
    >> authenticate the origin domainname as follows:
    >> 
    >> - use DNSSEC for all DNS queries needed to find the URI RRs and
    >> DANE to authenticate the authorities of the resulting URIs
    >> 
    >> or
    >> 
    >> - expect the target authorities to have certificates that
    >> authenticate the origin, using SNI if need be.
    >> 
    >> I would still drop everything related to NAPTR and DDDS.

    Viktor> That works for me, and is in reasonable alignment with

I would object strongly to this because of the trust anchor reasons I've
discussed.
I think applicability advice discussing when it's appropriate to trust
DNS and how the DNS trust models differ from the TLS trust model are an
important consideration to standards-track work in this space.
It doesn't sound like Nico's document would include sufficient
discussion of that to make me happy.
I think that within the case where trusting DNS makes sense, Nico's
advice isn't the advice I'd give, but I wouldn't go so far as to object
to it.



I don't actually think TLSA adds much to this discussion.  If you're
willing to trust DNS and if you're using DNSSec, I don't see why you
can't just trust the target of the redirection.
What are you getting out of forcing DANE?

TLSA doesn't help the case where the app has stronger trust anchors
(within its trust domain) than the DNS trust anchors.