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

[Phillip Hallam-Baker <[e-mail]>]

On Tue, Feb 24, 2015 at 11:49 AM, Paul Hoffman <[e-mail]>
wrote:

> On Feb 23, 2015, at 8:33 AM, Sam Hartman <[e-mail]> wrote:
> > Yes, I see significant security problems with this URI.
>
> It sounds like you have issues with URIs in general, not in a DNS RTYPE
> that carries a URI. That is, any URI that has a domain name that can lead
> to redirection (though CNAME, DNAME, or SRV) would have the properties that
> worry you. It that a fair summary?
>

I think Sam is raising an important point. But it is an easy one to solve.

The DNS is really providing multiple layers of lookup. The question is what
layer the TLS credentials should bind at and what assurances should be
presented to users if any. It is really independent of URI but it is an
important one.


Take the following discovery path

Application provides: Service: _new._ws   Domain: example.com

SRV / URI lookup returns

host1.example.net:443
host2.example.net:443

A / AAAA lookup returns

10.2.3.1:443
10.2.3.2:443

So the question is which TLS certificate should be accepted and what
assertions should be made to the end user?


I don't think the question can be properly be answered without considering
the security policy. At the moment we only have the security policy that
results from explicitly using https:// as the URI.

If someone types in https://www.example.com/ then I think it is clear that
the security policy is ONLY met if the site has a certificate for
example.com.

If someone types in http://www.example.com/ and then gets redirected to
https://www.example.net/ which has an EV certificate, then we have met the
security policy and we have an assurance the site has accountability. So we
can show a security indicator [but I am not going to say which one]

If someone types in http://www.example.com/ and we get back a redirect to
https://www.example.net/ and a DV cert then things are a little different.
The only fact that the cert is attesting to is something we allowed to be
overwritten with an untrusted redirect. We should definitely turn on TLS.
But we should not be telling the user they have any security because they
don't.


This does not map onto the SRV/URI lookup cleanly because we don't have the
notion of a security policy yet. In order to make it work we need to
specify what the security policy is.

Another difference is that SRV and URI should really be considered as being
equivalent to A or AAAA mappings rather than http redirects.


So in my view, if someone types in https://www.example.com/ and there is an
SRV record for _http._tcp, this is not semantically equivalent to a http
redirect as the address bar value does not change. There is no visual
signal. It is a purely internal DNS mapping like a CNAME record.


So I believe that for the example above, a Web Service client should:

* Only accept a TLS certificate for example.com for the purposes of meeting
a 'must meet EV' security policy.

* Accept a TLS cert for example.com OR a DNSSEC trust chain for a
SRV/URI/etc mapping and a TLS cert for host1.example.net for the purposes
of meeting a 'must meed DV'

* Accept any cert at all for the purposes of promiscuous encryption
accepting that this does not provide authentication or confidentiality
guarantees against active attack.