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
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail