Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

Nico Williams <> Fri, 27 February 2015 19:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 788F21AD358 for <>; Fri, 27 Feb 2015 11:50:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7SkeBRO0ERiW for <>; Fri, 27 Feb 2015 11:50:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9EF621AD363 for <>; Fri, 27 Feb 2015 11:50:23 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 5D5A49405E for <>; Fri, 27 Feb 2015 11:50:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to;; bh=RiJr7TeNpjO05N6nrnf96jYqG8c =; b=MzfrAYJyJNsm7US5F324Ci6WTNqNdUNIHHjihPBBWXthNzxcQY7T0dhy8YE a3LdAyCCfJ7zJzI3Ne1yH7WRhGzTjuqNiC+BGymnfL4xG3Du5ZOYgpynP2SUkgl5 GsZ3lCILVljfqiwQVa4WHEXPq46gmi673j6DN5APVmVMYKHM=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id 1E3109405C for <>; Fri, 27 Feb 2015 11:50:23 -0800 (PST)
Date: Fri, 27 Feb 2015 13:50:22 -0600
From: Nico Williams <>
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: <20150227195020.GB11145@localhost>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Feb 2015 19:50:33 -0000

On Fri, Feb 27, 2015 at 06:27:07PM +0000, Viktor Dukhovni 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 did not mean to imply a static choice.  Dynamic is fine.

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

The problem with an FYI that doesn't say these things is that people
will make use of the URI RR type without knowing the trap they're
walking into.  A document with proper text will do.

Alternatively, publish a BCP or Standards-Track RFC about how to use
indirection via DNS securely, then publish this I-D with merely a
reference to the former.  I think just fixing this I-D is the easier way
forward, and it's just one short section of prose.

> 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.

Yes, but given that the RR type has been registered and used, we should
not now hide our heads in the sand.

> 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.

Right, SMTP is one thing.  So it's been not secure for ages, but we've
also all understood this (and you're fixing it).  It's different for
*new* uses.

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