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

Viktor Dukhovni <> Wed, 25 February 2015 18:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 475291A037A for <>; Wed, 25 Feb 2015 10:02:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t26f2uYk5avt for <>; Wed, 25 Feb 2015 10:02:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A3B841A0033 for <>; Wed, 25 Feb 2015 10:02:29 -0800 (PST)
Received: by (Postfix, from userid 1034) id A9943282FCC; Wed, 25 Feb 2015 18:02:28 +0000 (UTC)
Date: Wed, 25 Feb 2015 18:02:28 +0000
From: Viktor Dukhovni <>
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: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
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: Wed, 25 Feb 2015 18:02:31 -0000

On Wed, Feb 25, 2015 at 05:28:35PM +0100, Patrik F?ltstr?m wrote:

> > Victor is correct.  This draft introduces indirection through DNS.
> > Typically in the past when we've done indirection through DNS, we've not
> > changed the expected security principal that we're targeting.
> > It's that change  that significantly changes the security model.
> It is not new with this draft and URI, it is done for example with SRV, and also MX.

DNS redirection indeed has precedents in MX and SRV records.
However, there is little to no prior practice in combining such
rediction with "strict" TLS wherein the client's reference identifier
for the server "chases" the redirection.

I am sure that some MTA implementations just blindly apply TLS
verification to the insecurely obtained MX hostname, even without
DNSSEC.  Such "going through the motions" is not in my view a real
precedent.  [ IIRC there was, and perhaps still is, a large email
filtering provider that verifies the name the server returns in
the clear in the first line of the EHLO response!  This too is not
a precedent for the proposed URI security model. ]

> That said, it is an important discussion to have, and I have
> waited for the DNS and Applications Community to talk about it.

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

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

Some considerations relevant to combining DNSSEC-validated redirection
(which updates the client's notion of what to expect in peer
certificates) appear in:

I should note that MTA-to-MTA SMTP is a specific opportunistic TLS
application with a long history of deployment, so the above reference
is about that singular use-case in which the issues are relatively
well understood.

With URIs, it is far less clear what applications are in scope,
and what their security requirements might be.  So a proper discussion
of DNS-based URI redirection might need to be described as a set
of considerations to apply when determining which schemes in the
URI to accept, when to "chase" the reference identifier to the
URI's target and even whether the DANE PKI might then be more
appropriate in some situations,