> On 5 mar 2015, at 17:36, Sam Hartman <hartmans-ietf@xxxxxxx> wrote: > >>>>>> "John" == John C Klensin <john-ietf@xxxxxxx> writes: > > John> If anything, the text now says too much because introductory > John> statements like "The basic mechanism for successful use of URI > John> works..." strongly imply that use of, and reliance on, DNSSEC > John> is the only way to accomplish successful (and safe) use. The > John> current Security Considerations section could be equated to an > John> Applicability Statement that said "unless DNSSEC is used, and > John> used as specified in this document, use of the URI RR is NOT > John> RECOMMENDED". I don't think that is either intended or > John> justified. > > I do think an applicability statement that says this RR is inappropriate > for situations where authentication of the accessed resource is desired > and DNSSec is not used. I think that's justified and hoped something > like that was intended by section 7. > I agree that there are uses where you don't care about the > authentication of the accessed resource where DNSSec is not required. I am reading what is said in this thread, and will try to come up with a security considerations section that explain the issues, but it must ultimately be up to whoever is using it to decide how to apply the policy. I do not feel comfortable having this document start go down the path of saying whether security mechanism A is better than B, if C is good enough for the Internet or such. 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 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. 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. 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. Patrik
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail