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

Tobias Gondrom <tobias.gondrom@gondrom.org> Thu, 24 March 2011 20:01 UTC

Return-Path: <tobias.gondrom@gondrom.org>
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 720C83A68C3 for <websec@core3.amsl.com>; Thu, 24 Mar 2011 13:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.231
X-Spam-Level:
X-Spam-Status: No, score=-95.231 tagged_above=-999 required=5 tests=[AWL=0.131, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueSXPE6X-x4G for <websec@core3.amsl.com>; Thu, 24 Mar 2011 13:01:33 -0700 (PDT)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id D863A3A68BC for <websec@ietf.org>; Thu, 24 Mar 2011 13:01:32 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=T9G/1PRIqufr1b1VnmyxtIaPTpR+G9/r7KKsFWWDudRvolDl15byXIeW5TD7UgKm/OL0dGc3gN2mWOJxPw1Fl5ubJZ19ciU6tGmdZj2u7/m5YthbhWTMS+9NioY78K9U; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding;
Received: (qmail 5203 invoked from network); 24 Mar 2011 21:02:43 +0100
Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 24 Mar 2011 21:02:43 +0100
Message-ID: <4D8BA3B9.2020504@gondrom.org>
Date: Thu, 24 Mar 2011 20:04:09 +0000
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110221 SUSE/3.1.8 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: websec@ietf.org
References: <1300937463.2117.224.camel@localhost> <AANLkTikdUn8sfLs18oUmBk4oeB13MLstn+Fgi5BbSRNM@mail.gmail.com> <1300938889.2117.239.camel@localhost>
In-Reply-To: <1300938889.2117.239.camel@localhost>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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:01:34 -0000

Hm, using a http header makes pinning a cert quite difficult, plus you
still have the trust on first use.
However HSTS is easy to deploy and will give improved security quickly
(even without the pinning).

As has been mentioned on the list earlier, there are considerations for
association of cert with protocol and domain using DNSSEC - though this
is a complicated matter.
Please take a look at dane: https://datatracker.ietf.org/wg/dane/charter/

BR, Tobias



On 03/24/2011 03:54 AM, 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.  But it may be a useful thing to do in light of the
> typical temporal and spatial scope of MITM attacks.  (Can anyone comment
> on this?)
>