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

John C Klensin <> Fri, 06 March 2015 06:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C0A0D1ACCE7 for <>; Thu, 5 Mar 2015 22:15:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.31
X-Spam-Status: No, score=-2.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wvpXtP0XS8Uv for <>; Thu, 5 Mar 2015 22:15:06 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8DCEC1ACCE1 for <>; Thu, 5 Mar 2015 22:15:06 -0800 (PST)
Received: from [] ( by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1YTlXE-000KEq-4o; Fri, 06 Mar 2015 01:14:56 -0500
Date: Fri, 06 Mar 2015 01:14:51 -0500
From: John C Klensin <>
To: =?UTF-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= <>, Sam Hartman <>
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: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Archived-At: <>
X-Mailman-Approved-At: Fri, 06 Mar 2015 08:08:20 -0800
Cc: Phillip Hallam-Baker <>,, Pete Resnick <>, Mark Nottingham <>
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, 06 Mar 2015 06:15:08 -0000

--On Thursday, March 05, 2015 20:01 +0100 Patrik Fältström
<> wrote:

> What about something like this:
> 7.  Security Considerations
>    DNS is a protocol both running over UDP and TCP, it also
> explicitly    uses proxies, for clients in many cases

Given that the term "proxy" does not appear in either 1034 or
1035 and is sometimes use to refer to something that intercepts
and changes DNS responses (exactly what DNSSEC is suppose to
prevent) I think you should either choose a different term or
provide a definition or reference.  Certainly "explicitly uses
proxies" is incorrect without such qualification.

> configured using DHCP.  An    extension to DNS has been
> developed called DNSSEC that give the    ability for the
> receiver of a response to a DNS query to validate an
> electronic signature.  With a proper validation the content
> can be    trusted to a much higher degree.

See my prior whine about trust models.  I think you should be
talking about an integrity check (on consistency between what is
stored in the DNS and the query response) here and not hand-wave
about "validation" or degrees of trust.  DNSSEC can be said to
verify that the records received at an endpoint )or the last
validation point) are consistent with what is stored under the
name for which the query was actually issued.  If should not
enhance the trust that the name that the user intended actually
reached a server.  Even if one ignores deliberate phishing, as
you know better than most, trust assertions about whether what
the user intended and what a server sees get very tricky when,
e.g., something like UTR 46 modifies the labels being looked up
before IDNA or query processing.

> One description of
> a threat model    to DNS, including description of what
> threats DNSSEC is intended to    defend against can be found
> in RFC 3833 [RFC3833].
>    If for example the URI resource record is not signed with
> the help of    DNSSEC and validated successfully, trusting the
> non-signed URI might    lead to a downgrade attack.

While this may be obvious to experts, the experts probably don't
need it.  For everyone else, you are probably missing a
statement about interception, changes to the query or URI, and a
system that won't respond as intended to STARTTLS or equivalent.
Note, in particular, that if one started out with: IN URI 0 0

and a query for that produced a response that contained IN URI 0 0

That would clearly be a problem for DNSSEC but, if both of the
hosts designated by "good" and "evil" responded to STAETTLS by
opening TLS connections at desired degrees of security, there
would be no downgrade attack, "only" a MITM host diversion

>    What also can happen is that the URI in the resource record
> type has    errors in it.  Applications using the URI resource
> record type for    resolution should behave similarly as if
> the user typed (or copy and    pasted) the URI.  At least it
> must be clear to the user that the    error is not due to any
> error from his side.
>    One SHOULD NOT include userinfo (see User Information,
> Section 3.2.1,    in RFC 3986 [RFC3986]) in a URI that is used
> in a URI resource record    as DNS data must be viewed as
> publicly available information.

Generally, while I think you should warn that URI records may
cause some risks that do not exist with, e.g., conventional name
to address mappings (note that the "downgrade attack or not"
considerations above would apply equally well to:  IN A
being diverted into a response of  IN A

(which would be, historically, a likely upgrade attack, but it
has nothing to do with URI records but is equally preventable by
an integrity check.))

As long as there is a warning, I really don't care very much
what you say, but whatever you do say should be as accurate as