Re: [websec] [saag] Pinning

Tobias Gondrom <> Sat, 18 August 2012 12:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0415F21F85A0 for <>; Sat, 18 Aug 2012 05:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -96.83
X-Spam-Status: No, score=-96.83 tagged_above=-999 required=5 tests=[AWL=-1.468, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V-iYvXztN1Pm for <>; Sat, 18 Aug 2012 05:03:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 61F5521F859B for <>; Sat, 18 Aug 2012 05:03:46 -0700 (PDT)
Received: (qmail 11476 invoked from network); 18 Aug 2012 14:03:44 +0200
Received: from (HELO ? ( by with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Aug 2012 14:03:44 +0200
Message-ID: <>
Date: Sat, 18 Aug 2012 13:03:43 +0100
From: Tobias Gondrom <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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: Sat, 18 Aug 2012 12:03:56 -0000

On 17/08/12 13:58, Alexey Melnikov wrote:
> On 10/08/2012 23:20, Chris Palmer wrote:
>> Hi all,
>> Resurrecting this ancient thread, and explicitly including Moxie and
>> Trevor in case they aren't already on any of the relevant mailing
>> lists.
>> So ultimately I do think we should decide on either HPKP or TACK, but
>> that we should make that decision after there has been some real-world
>> deployment experience with both (or, sadly, real-world non-deployment
>> of one or both).
>> Additionally, HPKP and TACK might converge, more or less. I have plans
>> to publish a new HPKP I-D that borrows some of TACK's pin activation
>> and expiration ideas, for example.
>> Additionally, one of the main criticisms of HPKP is that it is tied to
>> HTTP. I currently don't consider that a huge problem — even though I
>> consider TACK's TLS-generic-ness a nice benefit — for several reasons:
>> * HTTPS is the big, important application that we need to secure 
>> right now.
>> * IMAPS and POPS are surely on the list too, right after HTTPS; but
>> specifying "IPKP" and "PPKP" is likely to be relatively
>> straightforward once we get HPKP working.
> I am surely hoping there would be no IMAP, POP or SMTP extensions to 
> address this. IMHO, judging from past experiences of any new 
> functionality being adopted by IMAP/POP/SMTP, chances of such 
> extensions being deployed in any reasonable number of email clients 
> any time soon are close to 0. I think some more generic facility (like 
> a TLS extension) has much better chance of success.
> Having said that, I think it is Ok if an HTTP facility is deployed now 
> before the TLS extension is finalized.

I agree with Alexey on both: chances of deployment in email clients is 
unclear and that it is ok to get an HTTP facility deployed.

>> * It's not clear that SMTP over TLS is very beneficial, because you
>> can't stop delivery due to pin validation failure (or really even
>> regular old X.509 failure). You could use certificate errors as
>> soft-fail spam signals, but you can in principle do that now, too,
>> without explicit pinning. I don't know how much benefit you'd get from
>> using pin validation failure as a spam signal.