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
- [websec] Fwd: [saag] Pinning Paul Hoffman
- Re: [websec] Pinning Yoav Nir
- Re: [websec] [saag] Pinning Tobias Gondrom
- Re: [websec] [saag] Pinning Chris Palmer
- Re: [websec] [saag] Pinning Paul Hoffman
- Re: [websec] [saag] Pinning Trevor Perrin
- Re: [websec] [saag] Pinning Yoav Nir
- Re: [websec] [saag] Pinning Tom Ritter
- Re: [websec] [saag] Pinning Yoav Nir
- Re: [websec] [saag] Pinning Jeffrey Hutzelman
- Re: [websec] [saag] Pinning Tony Finch
- Re: [websec] [saag] Pinning Alexey Melnikov
- Re: [websec] [saag] Pinning Tobias Gondrom
- Re: [websec] [saag] Pinning Tobias Gondrom