--On Thursday, March 05, 2015 20:01 +0100 Patrik Fältström
<paf(_at_)frobbit(_dot_)se> 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