On Fri, October 12, 2012 1:57 am, Nicholas Weaver wrote: > > On Oct 12, 2012, at 9:45 AM, Tony Finch wrote: > > > Marc Lampo <[email protected]> wrote: > > > >> Before the draft was adopted as RFC I asked how to cope with proxies. > > > > Why are proxies a problem for DANE in particular, rather than TLS in > > general? > > Because how the proxies work is they add an additional root key into the > (victim) browser during some form of configuration. DANE makes the > injected root key no longer valid. > > Of course, certificate pinning and other techniques has the same problem, > and IMO, killing the idea of TLS proxies is a feature, so DANE's general > incompatibility with TLS proxies is a feature, not a bug.
Public Key Pinning, as implemented in Chromium, only evaluates pins against publicly trusted root certificates (that is, roots which participate in the various platforms' root certificate programs). When the certificate chain that was validated in the client does not terminate in a "publicy trusted" anchor, pinning is not enforced. If you have sufficient privileges to install a local trust anchor on a users machine - whether by means technical or policy - then such local settings are respected by Chromium. For users who are not operating in such scenarios, public key pinning offers a robust defense against future Diginotar-like misissuance. For users who do operate in such environments, it is presumed (albeit unlikely) that the (enterprise) endpoint terminating the TLS connection is performing these checks. In the reality that many such solutions are not, proposals such as http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01 or http://tools.ietf.org/html/draft-rpeon-httpbis-exproxy-00 would allow clients to implement such security policies. Such scenarios are not strictly relegated to "enterprise" scenarios, where there are effectively three parties participating in the end-to-end session (user, enterprise, site). It's unfortunately common that a number of antivirus vendors have begun shipping local "TLS proxies" as part of their traffic inspection anti-virus/user-protection platforms. These are solutions that the user directly opts in to (by choice of installing the antivirus and configuring it to do so). Thus, I'm not sure that RFC 1984 really comes into play here - this is the user wanting to configure a local policy that can be respected regardless of the applications running on their machine. For DANE, presumably solutions would use some form of DNSSEC rewriting, with DLV, to accomplish the equivalent. That, or individual applications would have explicit options to configure such scenarios. Of course, without some form of central trust mechanism - as exists on Windows and OS X, and as does not exist on most Linux-based distros - it's likely that many applications will end up trying to roll their own settings, and getting them wrong or being otherwise unmaintainable at scale. The same as it is today with application support for explicit (not TLS) proxies such as SOCKS or HTTP. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
