Hi Marc I assume you're talking about TLS proxies rather than HTTP proxies. Those are in a position to sign certificates on behalf of al the https servers in the world, that would be trusted by the client. If they have that kind of control, I don't see how they'd have any problem either filtering out TLSA records from DNS queries and responses or getting the client to trust their own signatures.
A draft from a few months ago ( http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01 ) would solve this problem, as it allows the client to see the real certificate. But that TLS extension was rejected, so it's pretty much dead. Yoav On Oct 12, 2012, at 9:28 AM, Marc Lampo 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 > > Scanned by Check Point Total Security Gateway. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
