--On Thursday, March 05, 2015 20:01 +0100 Patrik Fältström <paf@xxxxxxxxxx> 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