If the DNSSEC verifier (or whatever the correct term is) is inside the application doing TLS - it isn't a problem. (This *should* cover browsers, when they get around to implementing DANE.) It will probably be handled in the same way Certificate Pinning is handled. If a certificate is signed by a Root CA that is installed locally into the trust store - Certificate Pinning does not apply. Likewise, DANE would (probably) not apply.
For any application that does not have a local trust store to install root certificates in or does not perform it's own DNSSEC validation - proxies would indeed break DANE. And as mentioned, I think that is a feature, not a problem. If the application was willing to be proxied, it would support those features as hook points to manipulation trust validation. -tom On 12 October 2012 03:28, Marc Lampo <[email protected]> wrote: > Before the draft was adopted as RFC I asked how to cope with proxies. > > On Sector 2012, last week, I was quite shocked to hear a speaker (also > reading this, I assume) to simply state to get rid of them ! > I'd rather see continued work on how to make the principle of DANE > apply/work even in the presence of proxies. > > The other security remark is that, in order for the browser to use > info in TLSA record, the host needs access to public DNS. > (with the use of a proxy, a setup with internal-roots is possible, > internal hosts don't need access to public IP addresses > if they use proxies) > However, TLSA is not "an address", so access to public DNS is needed. > But that (access to public DNS) allows for new threats in the area of > data leakage !!! > One can do file transfer, both in and out of a network, using correct > DNS messages, if access to public DNS is available. > (as I addressed, when still Security Officer for EURid, on CENTR > Security WG meeting in June 2012, in Frankfurt) > > In summary : > Usage of TLSA, in its present form, opens new can of worms. > Which can only be kept closed if somehow collaboration of DANE (TLSA) > and proxies can be achieved. > > Regarding DNSSEC : > do not forget that adding signatures without verifying them is almost useless. > And since *lots* of networks use AD, with its (non DNSSEC capable) DNS > servers, only few users actually benefit, at this moment. > ("non DNSSEC capable" : since MS DNS does not support a protocol > higher than 5, and treats everything higher as "unsigned": > + since the root zone uses protocol 8 > --> this comes down to "not capable DNSSEC") > > So, wether or not the TLSA record is coming from a signed domain, most > users are not capable of noticing this anyway. > > Kind regards, > > Marc Lampo > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
