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> Fri, 27 February 2015 18:27 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 9D40E1A9123 for <ietf@ietfa.amsl.com>; Fri, 27 Feb 2015 10:27:09 -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 LDjp2FvUw6iI for <ietf@ietfa.amsl.com>; Fri, 27 Feb 2015 10:27:08 -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 1ED301A9176 for <ietf@ietf.org>; Fri, 27 Feb 2015 10:27:08 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 47B21282FC0; Fri, 27 Feb 2015 18:27:07 +0000 (UTC)
Date: Fri, 27 Feb 2015 18:27:07 +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: <20150227182707.GW1260@mournblade.imrryr.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAK3OfOjTs84ckEXanQrtQZU-ei-o5C0wRLQq4inQ8mb5cKXAow@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/s12LoxOXDIO4fI6X5mmGZ0pvNjs>
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: Fri, 27 Feb 2015 18:27:09 -0000

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.

That works for me, and is in reasonable alignment with

	draft-ietf-dane-srv

which ignoring the gory details says essentially the same thing,
but with the choice made dynamically, based on presence of "secure"
SRV and TLSA RRsets, rather than as a static prior dichotomy.

I am also fine with the informational variant.  Either way, perhaps
an informational reference to the DANE SRV draft would be helpful.

As an instigator of the security sub-discussion, I just wanted to
make sure than the document did not claim that introducing indirection
into HTTPS has minor security consequences.  Rather it is a significant
change in the threat analysis for any application that makes the switch.

Likely there are existing applications that have glossed over this
issue (going through the motions) with MX and SRV records, but any
such poor practices are not IMHO sufficient grounds to say that
the current text's security considerations match the scope of the
proposed semantics.

And I still support the proposed semantics, just with eyes wide
open to the security implications.

-- 
	Viktor.