Re: [websec] [saag] Pinning

Paul Hoffman <paul.hoffman@vpnc.org> Sat, 11 August 2012 17:57 UTC

Return-Path: <paul.hoffman@vpnc.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 D92D921F861C; Sat, 11 Aug 2012 10:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.582
X-Spam-Level:
X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EB57QPjUIhy; Sat, 11 Aug 2012 10:57:43 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 49E9521F8617; Sat, 11 Aug 2012 10:57:43 -0700 (PDT)
Received: from [10.20.30.100] (50-1-50-97.dsl.dynamic.fusionbroadband.com [50.1.50.97]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id q7BHvdS8049125 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 Aug 2012 10:57:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=windows-1252
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CAOuvq20iC817T-9U3zWG7S2Z=uU=G0i6usOT915ky+9FO8_Zwg@mail.gmail.com>
Date: Sat, 11 Aug 2012 10:57:42 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A20BCF75-BA32-42CF-80ED-82795D0C586F@vpnc.org>
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>
To: Chris Palmer <palmer@google.com>
X-Mailer: Apple Mail (2.1278)
Cc: IETF WebSec WG <websec@ietf.org>, IETF Security Area Advisory Group <saag@ietf.org>, Moxie Marlinspike <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, 11 Aug 2012 17:57:44 -0000

On Aug 10, 2012, at 3:20 PM, Chris Palmer wrote:

> Additionally, one of the main criticisms of HPKP is that it is tied to
> HTTP.

I am one of those people who expressed that criticism in the past. Having said that:

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

Fully agree to both. TACK is more general, but HPKP's specificity is an advantage for deployability and interoperability, and other TLS-using application protocols can copy what they need from it when it is 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.

Even if you could, the SMTP community hasn't spent much effort and thinking about the value of TLS failure as spam signals. Until they do, it is not wise for us to gate our work on them. If they deal with it, they can then deal with things like pinning issues.

> * SSH already has PKP. :)

And we can learn from that. And from the smiley.

> * The other common application protocols, like SIP, XMPP, and friends,
> are likely to also be pretty easy to extend in a manner similar to
> HPKP, "IPKP", and "PPKP".

Yes.

> And finally, as Ben Laurie pointed out, there is also Certificate
> Transparency. I personally consider the "public log" class of
> solutions (of which CT is a leading member, along with Sovereign Keys)
> to be The Real Solution. Pinning-like solutions (including HPKP and
> TACK) are a good, quick fix — as long as they are quick and simple.

"Here is what I say about them" proposals are orthogonal to "here is what I say about myself" proposals and should not be confused with each other.

--Paul Hoffman