Re: [websec] HSTS: pinning certs, other changes to TLS server authentication

Adam Barth <ietf@adambarth.com> Thu, 24 March 2011 20:41 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: websec@core3.amsl.com
Delivered-To: websec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCECB3A68D4 for <websec@core3.amsl.com>; Thu, 24 Mar 2011 13:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.314
X-Spam-Level:
X-Spam-Status: No, score=-2.314 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ikldp7jrk1-a for <websec@core3.amsl.com>; Thu, 24 Mar 2011 13:41:42 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 0C6BB3A6846 for <websec@ietf.org>; Thu, 24 Mar 2011 13:41:41 -0700 (PDT)
Received: by vxg33 with SMTP id 33so361317vxg.31 for <websec@ietf.org>; Thu, 24 Mar 2011 13:43:16 -0700 (PDT)
Received: by 10.52.0.5 with SMTP id 5mr9494129vda.120.1300999396478; Thu, 24 Mar 2011 13:43:16 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by mx.google.com with ESMTPS id u6sm139351vby.7.2011.03.24.13.43.12 (version=SSLv3 cipher=OTHER); Thu, 24 Mar 2011 13:43:13 -0700 (PDT)
Received: by qwg5 with SMTP id 5so257819qwg.31 for <websec@ietf.org>; Thu, 24 Mar 2011 13:43:12 -0700 (PDT)
Received: by 10.224.216.197 with SMTP id hj5mr7436069qab.264.1300999392059; Thu, 24 Mar 2011 13:43:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.45.85 with HTTP; Thu, 24 Mar 2011 13:42:42 -0700 (PDT)
In-Reply-To: <0C57AABE-3A40-4900-83D2-E59170EF020E@w3.org>
References: <1300937463.2117.224.camel@localhost> <AANLkTikdUn8sfLs18oUmBk4oeB13MLstn+Fgi5BbSRNM@mail.gmail.com> <1300938889.2117.239.camel@localhost> <0C57AABE-3A40-4900-83D2-E59170EF020E@w3.org>
From: Adam Barth <ietf@adambarth.com>
Date: Thu, 24 Mar 2011 13:42:42 -0700
Message-ID: <AANLkTinnHOd6CKCqEGa3Wm7t2Tc98vCXWd7gVy8ua4ff@mail.gmail.com>
To: Thomas Roessler <tlr@w3.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: websec@ietf.org
Subject: Re: [websec] HSTS: pinning certs, other changes to TLS server authentication
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 24 Mar 2011 20:41:43 -0000

On Thu, Mar 24, 2011 at 5:03 AM, Thomas Roessler <tlr@w3.org> wrote:
> On 24 Mar 2011, at 04:54, Matt McCutchen wrote:
>> On Wed, 2011-03-23 at 20:36 -0700, Adam Barth wrote:
>>> Thanks for forwarding the thread.  There have been a bunch of people
>>> asking for the ability to pin a certificate (or a CA certificate)
>>> using HSTS.  In light of recent events, that's sounding more and more
>>> like something we should consider.
>>
>> Maybe.  Pinning certs is a stopgap; it obviously doesn't work on the
>> first connection, and it places potentially significant operational
>> constraints on the web site.  I have a hard time seeing it as a step
>> toward a coherent server authentication scheme that solves the problems
>> we are facing today.
>
> Stephen Farrell looked at parts of the problem a while ago and came up with a mechanism for cert switch-overs that he documented in RFC 5697.  Perhaps useful here.

Thanks for pointing out this RFC.  Unfortunately, this approach
doesn't work in the "rouge CA" threat model because the CA is
responsible for verifying that the old and new certificates were
issued to the same entity.  My understanding is that the rouge CA
threat model is of paramount importance to the folks interested in
certificate pinning, making this approach non-viable for our purposes.

Adam