Re: (short version) Re: Last Call: <draft-faltstrom-uri-10.txt> (The Uniform Resource Identifier (URI) DNS Resource Record) to Proposed Standard

[Eliot Lear <[e-mail]>]

On 2/24/15 6:02 PM, Viktor Dukhovni wrote:
> On Mon, Feb 23, 2015 at 11:33:11AM -0500, Sam Hartman wrote:
>
>>     Viktor>     "The authors do not believe this resource record cause
>>     Viktor> any new security problems."
>>
>> Yes, I see significant security problems with this URI.
> With MX and SRV indirection, prior to DNSSEC/DANE, TLS applications
> have generally used the service domain (not the target domain) as
> the relevant reference identifier.  Also MX and SRV records do not
> specify whether TLS is or is not to be used, that decision is made
> by other means.  Here, the language specifies using the target,
> which makes the DNS trusted as with DNSSEC/DANE and this seems
> unavoidable, because the URI includes the scheme!

I think the real issue here we are concerned about is this:

Given a slightly modified example from your document:

   $ORIGIN example.net.
   _http._web    IN URI 10 1 "httpS://www.example.com/"

If the intent here is to declare an equivalence between
http://example.com and https://www.example.com the problem is that
absent DNSSEC one is subject to a downgrade attack.  Thus a browser
cannot trust the equivalence.

Eliot

>
> One might make the case that it is not the new DNS RRtype itself
> that changes the security model.  Rather, it would be its use in
> with a particular protocol.  This document then just provides the
> means, and future documents specify when URI records are (or are
> not) to be applied to a particular application protocol.  The draft
> then just defines the record type format, with specific discussion
> of when to use it, exactly how to decide whether TLS is required
> and which PKI to use deferred to documents that specify a particular
> application context.
>
>> In particular, prior to this URI, your security depends on your TLS
>> trust anchors.  Since this RR encourages folks to validate the
>> certificate in the target URI, not the expected name entered by the
>> user, even if DNSSec validation is done, the security now depends on the
>> DNS trust anchors and the TLS trust anchors.
> Yes, both, in a way that means that compromise of either breaks
> security.  So at the very least, I would advocate to go with DANE
> for verification: in for a penny, in for a pound!  Adding a second
> set of trusted parties increases exposure without any compensating
> increase in security.
>