Re: [websec] #58: Should we pin only SPKI, or also names

Yoav Nir <ynir@checkpoint.com> Fri, 02 August 2013 01:04 UTC

Return-Path: <ynir@checkpoint.com>
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 641CC11E82BF for <websec@ietfa.amsl.com>; Thu, 1 Aug 2013 18:04:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.474
X-Spam-Level:
X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 gF1lnmpB3Bmf for <websec@ietfa.amsl.com>; Thu, 1 Aug 2013 18:04:42 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF1D11E82D6 for <websec@ietf.org>; Thu, 1 Aug 2013 17:06:03 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r7205qdh014832; Fri, 2 Aug 2013 03:05:52 +0300
X-CheckPoint: {51FAF7E0-A-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([169.254.2.105]) by DAG-EX10.ad.checkpoint.com ([169.254.3.223]) with mapi id 14.02.0342.003; Fri, 2 Aug 2013 03:05:52 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Thread-Topic: [websec] #58: Should we pin only SPKI, or also names
Thread-Index: AQHOjHagv3/BmvZ4wU6WrbkIw+Bd/ZmAXZOAgAADk4CAAHu6gA==
Date: Fri, 02 Aug 2013 00:05:51 +0000
Message-ID: <6125A841-6C85-4858-B37F-C021067F0CFA@checkpoint.com>
References: <060.be9b0009dc0350ca543f553042673944@trac.tools.ietf.org> <073501ce8c6e$f6c17d90$e44478b0$@digicert.com> <CAMm+LwjdGJC4FHCJ_OAYGRqCGGc0Nz1pLV=yVGK9M9E7drfujQ@mail.gmail.com> <CAOuvq200e9HnPX1w9sZ+e7ipBmdgZdPL5xzKDgcaDpSxz1N=gg@mail.gmail.com> <CAMm+Lwh384YBMXw-BDoxJw+AN4qv8x6GQpF9YK4PW1gQRnadpg@mail.gmail.com>
In-Reply-To: <CAMm+Lwh384YBMXw-BDoxJw+AN4qv8x6GQpF9YK4PW1gQRnadpg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.20.134]
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 118462de19621d1f8003d384449cd3b5ae46852d01
Content-Type: multipart/alternative; boundary="_000_6125A8416C854858B37FC021067F0CFAcheckpointcom_"
MIME-Version: 1.0
Cc: websec <websec@ietf.org>
Subject: Re: [websec] #58: Should we pin only SPKI, or also names
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: Fri, 02 Aug 2013 01:04:54 -0000

On Aug 1, 2013, at 6:43 PM, Phillip Hallam-Baker <hallam@gmail.com<mailto:hallam@gmail.com>> wrote:




On Thu, Aug 1, 2013 at 12:30 PM, Chris Palmer <palmer@google.com<mailto:palmer@google.com>> wrote:
On Mon, Jul 29, 2013 at 9:13 AM, Phillip Hallam-Baker <hallam@gmail.com<mailto:hallam@gmail.com>> wrote:

> If we have a diginotar type situation again (FSM forefend), we want the pins
> to a root to be broken at the same time the root is unloaded, yes?

If the root of a site's cert chain --- really, any signer --- is
blacklisted or even just removed from the trust anchor store, pins and
Pin Validation are irrelevant since the chain won't validate. Pin
Validation happens only *after* all other certificate chain checks are
performed.

My point is that the people who were customers of Diginotar had to get new certs quickly. The Dutch government has complained in several forums about the way in which the Diginotar root was revoked. They had an entire national port unable to function as a result.

If the root is revoked, the pins have to become inoperable and allow a user to get a cert from any vendor.

To me this seems too hard for the browser. This is especially true if the pins were for a sub-CA rather than the root CA.

Continuity of business is an issue here.

Yes, it is. That is what the backup pin feature is for, and why it is mandatory in the draft.

Yoav