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> Mon, 23 February 2015 15:52 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 C924A1A1B6B for <ietf@ietfa.amsl.com>; Mon, 23 Feb 2015 07:52:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level:
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6] 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 6O4---VSwfj0 for <ietf@ietfa.amsl.com>; Mon, 23 Feb 2015 07:52:51 -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 12C021A1B67 for <ietf@ietf.org>; Mon, 23 Feb 2015 07:52:49 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EDC44282F52; Mon, 23 Feb 2015 15:52:41 +0000 (UTC)
Date: Mon, 23 Feb 2015 15:52:41 +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: <20150223155241.GJ1260@mournblade.imrryr.org>
References: <20150127223859.28024.43756.idtracker@ietfa.amsl.com> <4257D8A3-0EFE-40E3-B0AD-8E23772B7693@mnot.net> <6F9BB11D-C224-4D7B-A06C-41EACBAAB4B2@netnod.se> <54C9DA42.5040901@cisco.com> <9EB44D8A-278B-42FC-A542-1C182AD43128@netnod.se> <A74A30F4D1214630918FD4CA@JcK-HP8200.jck.com> <20150223153757.GI1260@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20150223153757.GI1260@mournblade.imrryr.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/1pzB6_UIpzBSyL4tTzT1P_I3HXA>
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: Mon, 23 Feb 2015 15:52:52 -0000

On Mon, Feb 23, 2015 at 03:37:57PM +0000, Viktor Dukhovni wrote:

> > I do note that having "priority" and "weight" separated is not
> > well-motivated (or even explained) in either this document or in
> > the original application. 
> 
> This is simply carried over verbatim from SRV, where priorities
> yield strict ordering, while weights (for entries with the same
> priority) support weighted load-sharing.  This draft does not appear
> to differ from SRV except in replacing target+port with an URI.

I neglected to comment on the "Security Considerations" section.

As observed in the DANE SMTP draft (draft-ietf-dane-smtp-with-dane-14
section 1.3.2) mixing DNS indirection with TLS significantly changes
the security picture.  The URI draft mentions the need for DNSSEC
but likely understates the significance of the impact.

For example, what determines whether to use TLS?  The target URI,
or some prior policy in the application?  Must URI RRsets always
be DNSSEC validated?  If not what prevents downgrade attacks to
HTTP?  If the DNS (via DNSSEC) is a critical "trusted entity",
should not then TLS use the DANE PKI (any DNS compromise cannot be
compensated for by a public CA validating a URI that has been
redirected to a hostile site)?

So I take issue with the opening sentence of "Security Considerations".

    "The authors do not believe this resource record cause any new
     security problems."

I think the use of DNS indirection via URI RRs (as also with SRV,
MX, ...) profoundly changes the security model for TLS.

-- 
	Viktor.