Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uni

> On 5 mar 2015, at 17:36, Sam Hartman <hartmans-ietf(_at_)mit(_dot_)edu> wrote:
>
> > > > > > "John" == John C Klensin <john-ietf(_at_)jck(_dot_)com> 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

signature.asc
Description: Message signed with OpenPGP using GPGMail