Re: [websec] [saag] Pinning

Tobias Gondrom <> Wed, 06 June 2012 16:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 779EA21F86B5 for <>; Wed, 6 Jun 2012 09:46:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -96.778
X-Spam-Status: No, score=-96.778 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FOZxaKUqUb4L for <>; Wed, 6 Jun 2012 09:46:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CD83921F8718 for <>; Wed, 6 Jun 2012 09:46:20 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default;; b=cnxEZrk3HfqFHoJsXYYRgtdHcSxkG+7/7vZ35VgtazUVPdxd7RofFS3pgZMnCTHfT1IIW+LfkdgOmbp0rAA4w9OaAsTunL/Uyps2Vc3Gy8t68WqWe1nd6NP6Cllkf2sc; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
Received: (qmail 3983 invoked from network); 6 Jun 2012 18:46:04 +0200
Received: from (HELO ? ( by with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Jun 2012 18:46:04 +0200
Message-ID: <>
Date: Wed, 06 Jun 2012 17:46:03 +0100
From: Tobias Gondrom <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [websec] [saag] 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: Wed, 06 Jun 2012 16:46:21 -0000

Sean et al.,

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.

Best regards, Tobias

<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.

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.
>>> 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 would be clearer if you said "both key-pinning in HTTP and key-pinning in TLS (tack)".
> --Paul Hoffman
> _______________________________________________
> saag mailing list