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 <[e-mail]>]

--On Thursday, March 05, 2015 20:01 +0100 Patrik Fältström
<[e-mail]> 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:


  foo.example.com. IN URI 0 0  good.example.com.

and a query for that produced a response that contained
  foo.example.com. IN URI 0 0  evil.example.com.

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

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

  foo.example.com.  IN A 10.2.0.44
being diverted into a response of 
  foo.example.com.  IN A 10.0.0.6

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

   john