Re: [websec] Pinning

Yoav Nir <> Tue, 05 June 2012 21:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8EF3A21F877F for <>; Tue, 5 Jun 2012 14:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.544
X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lEEc54jYvhYp for <>; Tue, 5 Jun 2012 14:11:44 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E4CFE21F8790 for <>; Tue, 5 Jun 2012 14:11:43 -0700 (PDT)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id q55LBdj5005820 for <>; Wed, 6 Jun 2012 00:11:39 +0300
X-CheckPoint: {4FCE8204-1-1B221DC2-2FFFF}
Received: from ([]) by ([]) with mapi; Wed, 6 Jun 2012 00:11:36 +0300
From: Yoav Nir <>
To: IETF WebSec WG <>
Date: Wed, 06 Jun 2012 00:11:37 +0300
Thread-Topic: Pinning
Thread-Index: Ac1DX8p9p9nnInxWRYe1ZCiK1HFbaA==
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 11531ffdc5932c5e6c6409c08c7d27a50c8a447b4b
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [websec] Pinning
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Jun 2012 21:11:45 -0000


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:

An answer by the draft authors is here:

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.


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 <>
>> Subject: [saag] Pinning
>> Date: June 5, 2012 12:55:29 PM PDT
>> To:
>> 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 (, in the application after TLS has happened once, to be remembered in the future (, and in the TLS handshake ( 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 ( 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