[websec] Outstanding Issues on draft-ietf-websec-key-pinning-01

Tom Ritter <tom@ritter.vg> Thu, 16 February 2012 21:01 UTC

Return-Path: <tom@ritter.vg>
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 9F77B21F8633 for <websec@ietfa.amsl.com>; Thu, 16 Feb 2012 13:01:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.945
X-Spam-Level:
X-Spam-Status: No, score=-2.945 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 8KZpNj2Bvqff for <websec@ietfa.amsl.com>; Thu, 16 Feb 2012 13:01:38 -0800 (PST)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5EB21F8617 for <websec@ietf.org>; Thu, 16 Feb 2012 13:01:37 -0800 (PST)
Received: by eekc41 with SMTP id c41so1103510eek.31 for <websec@ietf.org>; Thu, 16 Feb 2012 13:01:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:from:date:message-id:subject:to:content-type; bh=yzXjAyudlTGgXwv2t8p4UOSVYYKXvUoY64uOD1Bzsjs=; b=azFGy/MkBPO9w4eKk27wCKrkXl7+PJPuU9qj+v5rz+BK3mHeb8Cg09vyekL1ON2Q41 Kf4sx6K50LYxnEgDVY44D9676gViBhTl38xZvT9v81aSYIcPKc+0rCNyQJYzu4+VYbdi s7wZkm7aCK3HYAH6UVcMaGQ2GHPxCMbWe1Phk=
Received: by 10.112.51.193 with SMTP id m1mr1626141lbo.58.1329426097144; Thu, 16 Feb 2012 13:01:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.38.4 with HTTP; Thu, 16 Feb 2012 13:01:17 -0800 (PST)
From: Tom Ritter <tom@ritter.vg>
Date: Thu, 16 Feb 2012 16:01:17 -0500
Message-ID: <CA+cU71ktj6oWYjeqTicefz5oqCeR7Zn-tGNh7yxBMHRdaoywYA@mail.gmail.com>
To: IETF WebSec WG <websec@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQm/PI6sGI5TDcvi4+UpD+nW2DvU+Gu0lqew4KEuAQuCcsF1BZ5J6qgBpAFwU0jw+Kqw6nBZ
Subject: [websec] Outstanding Issues on draft-ietf-websec-key-pinning-01
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: Thu, 16 Feb 2012 21:01:42 -0000

In 2.3, I believe

If the Public-Key-Pins response header field does not meet all four
   of these criteria

should be "all three of these criteria" by my bullet-point count.

To close up the hole with inherited parameters, in 2.2, prior to the
"We pin public keys" note, add:

  If the SubjectPublicKeyInfo of a certificate is incomplete when taken
  in isolation, such as when holding a DSA key without domain parameters,
  a public key pin cannot be formed.

And in 2.4, adding a phrase to the parenthetical comment in the big paragraph :

   If the connection has no errors, the UA will then apply a new
   correctness check: Pin Validation.  To perform Pin Validation, the UA
   will compute the fingerprints of the SPKI structures in each
   certificate in the host's validated certificate chain.  (The UA
   ignores certificates whose SPKI cannot be taken in isolation and
   superfluous certificates in the chain that do not form part
   of the validating chain.)  The UA will then check that the set of
   these fingerprints intersects the set of fingerprints in that host's
   Pinning Metadata.  If there is set intersection, the UA continues
   with the connection as normal.  Otherwise, the UA MUST treat this Pin
   Failure as a non-recoverable error.

Finally, I'd suggest the following change to 2.3.1, clarifying it's
required-ness and a max-age of 0.

2.3.1.  max-age

   max-age specifies the number of seconds, after the reception of the
   Public-Key-Pins HTTP Response Header, during which the UA regards the
   host as a Pinned Host.  The delta-seconds production is specified in
   [rfc-2616].

   max-age is a required attribute. If omitted, the UA MUST NOT note the
   host as a Pinned Host, and MUST discard any previously set Pinning
   Metadata for that host in its non-volatile store.

   If max-age is set to 0, the UA MUST likewise discard any previsouly
   set Pinning Metadata.

I won't be insulted if you dislike my wording, but I think this is a
complete summary of raised oustanding issues on -01.

-tom