Subject: [websec] Fwd: [saag] Pinning

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Jun 2012 13:47:49 -0700

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 <[email-masked]>
> Subject: [saag] Pinning
> Date: June 5, 2012 12:55:29 PM PDT
> To: [email-masked]
> 
> 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
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Jun 2012 00:11:37 +0300

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

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 06 Jun 2012 17:46:03 +0100

Sean et al.,

<hat="individual">
I agree with Paul and Yoav and think the coordination between dane and 
websec on HSTS and key-pinning is ok. Both WGs are aware of potential 
coordination issues when mechanisms in both (DNSSEC and HTTP header) 
will be implemented eventually. I don't think we need an operations 
statement yet. Maybe at some point in the future an informational Best 
Practice or if you wish a Std Track can help.

With regards to draft-perrin-tls-tack and draft-ietf-websec-key-pinning, 
I am not so sure about potential conflicts here and whether we need or 
want both.
</hat>

Best regards, Tobias

Ps.:
<hat="WG chair">
And on a personal note, one thing I am not so happy about is that I can 
see from the tls-tack draft, that the authors are aware of key-pinning 
(which is nice) and perceive that there would be flaws, yet they chose 
to not post their comments on it to websec nor inform the WG about their 
new draft.

To make it easier in the future to coordinate the two drafts and 
possibly discuss and decide whether to boil down to one, it might make 
sense to inform websec about draft-perrin-tls-tack and have a discussion 
about it at some point there.
Just my 5cents.
</hat>

On 05/06/12 23:01, Paul Hoffman wrote:
> On Jun 5, 2012, at 2:46 PM, Yoav Nir wrote:
>
>>> The similarity of pinning and DANE has been discussed before. DANE relies on DNSSEC being deployed, which key-pinning does not.
> Correct. Further, key-pinning in HTTP only applies to HTTP and relies on the client being able to establish a TLS session using non-key-pinning semantics. Key-pinning in TLS relies works with any lower-layer protocol and relies on the client being able to establish a TLS session using non-key-pinning semantics.
>
>>> Come to think of it, the draft needs a section comparing with DANE, but that's for another thread.
>>>
>>> The obvious question is why would we need both key-pinning and tack.
> It would be clearer if you said "both key-pinning in HTTP and key-pinning in TLS (tack)".
>
> --Paul Hoffman
>