Hi The similarity of pinning and DANE has been discussed before. DANE relies on DNSSEC being deployed, which key-pinning does not. Come to think of it, the draft needs a section comparing with DANE, but that's for another thread.
draft-perrin-tls-tack seems to tackle the same problem as key-pinning. Instead of the pins getting attested to in HTTP headers, you have a special public/private key pair, that you use to sign the SPKI from the server certificate within the a TLS extension. Like key-pinning there's a TOFU element here, because the client only learns about the special key when it encounters it in a TLS handshake. The obvious question is why would we need both key-pinning and tack. It has been asked on the TLS mailing list: http://www.ietf.org/mail-archive/web/tls/current/msg08818.html An answer by the draft authors is here: http://www.ietf.org/mail-archive/web/tls/current/msg08830.html In the grand scheme of things, it's not good for the IETF to make >1 standards, both of which need to be implemented in both servers and browsers, that accomplish the same thing, and Sean is correct that implementing more than one may lead to mismatching information. In a sense DANE is also doing the same thing, but DANE requires DNSSEC everywhere, so it's operational profile is different. But Tack and cert pinning both have no prerequisites and accomplish the same thing, so what if one's at the HTTP layer, while the other is at the TLS layer. I don't think the TLS WG is very excited about TACK (see the mailing list) but regardless, I think it's up to us to look at both options and decide if we would like to go on with cert-pinning, or whether we thing TACK is better. Yoav On Jun 5, 2012, at 11:47 PM, Paul Hoffman wrote: > From the SAAG mailing list, but appropriate here. I bet that Sean would > appreciate all discussion to go on on the SAAG mailing list... > > Begin forwarded message: > >> From: Sean Turner <turn...@ieca.com> >> Subject: [saag] Pinning >> Date: June 5, 2012 12:55:29 PM PDT >> To: s...@ietf.org >> >> All, >> >> There are many proposals for how to say which key or certificate or trust >> anchor should be used by the client in a TLS session that it is about to >> open. These proposals include making that decision in the DNS >> (https://datatracker.ietf.org/doc/draft-ietf-dane-protocol/), in the >> application after TLS has happened once, to be remembered in the future >> (https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/), and in >> the TLS handshake (https://datatracker.ietf.org/doc/draft-perrin tls-tack/). >> If more than one of these protocols are deployed, operational mistakes could >> lead to a client getting conflicting information. >> >> Similarly, there are also proposals on how to say whether or not a client >> should expect to see a particular service running under TLS. These proposals >> include making that indication in the DNS (draft hoffman-server-has-tls, >> expired but might be revived) and in the application after TLS has happened >> once, to be remembered in the future >> (https://datatracker.ietf.org/doc/draft-ietf-websec-strict-transport sec/). >> If more than one of these protocols are deployed, operational mistakes could >> lead to a client getting conflicting information. >> >> Is a standards-track operations statement needed to describe the choices >> that a TLS server administrator has, and to deal with conflicts between the >> proposals? >> >> spt _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
