On Tue, Feb 24, 2015 at 11:49 AM, Paul Hoffman <paul.hoffman@xxxxxxxx> wrote:
On Feb 23, 2015, at 8:33 AM, Sam Hartman <hartmans-ietf@xxxxxxx> 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
A / AAAA lookup returns
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.