Re: [websec] [saag] Pinning

Tobias Gondrom <tobias.gondrom@gondrom.org> Sat, 18 August 2012 12:03 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0415F21F85A0 for <websec@ietfa.amsl.com>; Sat, 18 Aug 2012 05:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -96.83
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-iYvXztN1Pm for <websec@ietfa.amsl.com>; Sat, 18 Aug 2012 05:03:54 -0700 (PDT)
Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id 61F5521F859B for <websec@ietf.org>; Sat, 18 Aug 2012 05:03:46 -0700 (PDT)
Received: (qmail 11476 invoked from network); 18 Aug 2012 14:03:44 +0200
Received: from 94-194-102-93.zone8.bethere.co.uk (HELO ?192.168.1.65?) (94.194.102.93) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Aug 2012 14:03:44 +0200
Message-ID: <502F849F.6040505@gondrom.org>
Date: Sat, 18 Aug 2012 13:03:43 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120714 Thunderbird/14.0
MIME-Version: 1.0
To: alexey.melnikov@isode.com
References: <31946C2A-4ACD-46D7-8977-49B681204A7B@checkpoint.com> <8E52CEC5-4FEB-4464-AB11-21F1B9208C5C@checkpoint.com> <38489744-05A9-45F0-A752-7F0B9E96E641@vpnc.org> <4FCF894B.8080002@gondrom.org> <CAOuvq20iC817T-9U3zWG7S2Z=uU=G0i6usOT915ky+9FO8_Zwg@mail.gmail.com> <502E3FDB.8060800@isode.com>
In-Reply-To: <502E3FDB.8060800@isode.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: cevans@google.com, websec@ietf.org, paul.hoffman@vpnc.org, saag@ietf.org, moxie@thoughtcrime.org
Subject: Re: [websec] [saag] Pinning
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=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.

<hat="individual">
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.
>>
>