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

Security issues related to URL resolution is as we all know complicated.

We do DNS lookup, and we do HTTP requests.

Redirect (equivalents) can happen in either.

We have various security mechanisms for both.

The ultimate solution that the IETF work with is that one have DNSSEC that 
covers everything we get from DNS, it is validated positively, and TLS session 
is used, and with the help of DANE the certificate is trusted and in turn the 
DN in the cert is compared with the host connected to.

Now, this is not deployed yet.

Today I claim the normal mechanism is:

1. Take URL

2. Lookup A/AAA without DNSSEC validation

3. Open HTTP connection and fetch data

What we are moving towards is to start with, which happens now and then:

1. Take URL

2. Lookup A/AAA with DNSSEC validation in a trusted resolver (not locally)

3. Open HTTP connection and fetch data

4. Get a redirect to the TLS version of the site

5. Open TLS connection, validate DN in cert with host, and local root cert

In this example, we have a few weak issues:

A. Trust resolver that do the validation
B. Get a redirect from non-TLS protected connection
C. The CA validation chain

With URI we get:

1. Take URL

2. Lookup URL RR with DNSSEC validation in a trusted resolver (not locally)

3. Lookup A/AAA with DNSSEC validation in a trusted resolver (not locally)

4. Open HTTP connection and fetch data

5. Get a redirect to the TLS version of the site

6. Open TLS connection, validate DN in cert with host, and local root cert

Now, we want to improve this even more, and get ultimately (if one use URI):

1. Take URL

2. Lookup URL RR with DNSSEC validation and do local validation

3. Lookup A/AAA with DNSSEC validation and do local validation

4. Open TLS connection, validate DN in cert grabbed with DANE (using DNSSEC and 
local validation) with host


So yes, of course there are weaknesses in a URI RR if one does not validate the 
response from DNS (directly or indirectly by trusting the validator). Just like 
one must trust the redirect in HTTP by validating cert used for TLS in a proper 
way. Both when DANE is in use requires proper DNSSEC signatures.

   Patrik

signature.asc
Description: Message signed with OpenPGP using GPGMail