Re: [websec] [saag] Pinning

Jeffrey Hutzelman <jhutz@cmu.edu> Sat, 11 August 2012 22:18 UTC

Return-Path: <jhutz@cmu.edu>
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 D0F5A21F8510; Sat, 11 Aug 2012 15:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 hPqkBM2-prfs; Sat, 11 Aug 2012 15:18:25 -0700 (PDT)
Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 2120321F84D6; Sat, 11 Aug 2012 15:18:25 -0700 (PDT)
Received: from [192.168.202.154] (pool-74-111-100-191.pitbpa.fios.verizon.net [74.111.100.191]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q7BMIIL8021870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 11 Aug 2012 18:18:19 -0400 (EDT)
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Chris Palmer <palmer@google.com>
In-Reply-To: <22134_1344637228_q7AMKQRp022297_CAOuvq20iC817T-9U3zWG7S2Z=uU=G0i6usOT915ky+9FO8_Zwg@mail.gmail.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> <22134_1344637228_q7AMKQRp022297_CAOuvq20iC817T-9U3zWG7S2Z=uU=G0i6usOT915ky+9FO8_Zwg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Sat, 11 Aug 2012 18:18:18 -0400
Message-ID: <1344723498.15925.63.camel@destiny.pc.cs.cmu.edu>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3
Content-Transfer-Encoding: 7bit
X-Scanned-By: mimedefang-cmuscs on 128.2.217.197
X-Mailman-Approved-At: Mon, 13 Aug 2012 00:42:15 -0700
Cc: Chris Evans <cevans@google.com>, websec@ietf.org, paul.hoffman@vpnc.org, saag@ietf.org, Moxie Marlinspike <moxie@thoughtcrime.org>, jhutz@cmu.edu
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 22:18:25 -0000

On Fri, 2012-08-10 at 15:20 -0700, Chris Palmer wrote:

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

That depends.  Key pinning may not be very interesting for accepting
coming mail from unknown sources, but it may be very interesting when
TLS is used for communication between cooperating components of an
enterprise mail system, or with an outsourced anti-smap or anti-virus or
backup MX service.  And of course, it's also interesting when TLS is
used to protect authenticated mail submission services -- a user sending
outgoing mail via his ISP probably doesn't want to tell his username and
password to just anyone.

> * SSH already has PKP.


Well, no.  Certainly, SSH clients making a leap-of-faith connection to a
previously unknown host will generally remember that host's public key.
And yes, once a host's public key is known, clients will generally
reject a host that presents a public key other than the one known for
that host.  But then, web browsers do the same thing for leap-of-faith
connections to web servers, when a server has a self-signed certificate
or one signed by an unknown CA.  But while this behavior is common, it
is not required by any standard, not something I'd expect an SSH client
to do when an X.509 certificate is used, and not the same thing as key
pinning.

So in fact, if this gets done at the application layer, it likely will
eventually have to happen for SSH, too.


I would really rather not see a proliferation of application-layer
extensions to handle pinning of the long-term keys used for TLS.  While
I haven't participated in previous discussion on this question, I think
that in the long run this is much better handled at the TLS layer.

That said, there may be a benefit to solving the problem for HTTP at the
HTTP layer, _if_ doing so allows us to get something deployed more
quickly than a TLS-layer solution.

-- Jeff