Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt

Tom Ritter <> Fri, 19 October 2012 14:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D7E221F8699 for <>; Fri, 19 Oct 2012 07:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.731
X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CtEJXCfLDkyq for <>; Fri, 19 Oct 2012 07:29:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 78DEA21F869E for <>; Fri, 19 Oct 2012 07:29:52 -0700 (PDT)
Received: by with SMTP id fc26so636499vbb.31 for <>; Fri, 19 Oct 2012 07:29:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=xxBBiXVe+oR3BytNmNWhUaDfgAkB6scADaKHw/G5Z48=; b=Ua6nMJgEPNaRw7Nz0pCtgfgKli4X9AYMmGhMkpwJq8CQH1EVGC3GSnrXzJDK7zFBOY 7cwZMtbMMjWY7RymVorJqbrxXnXsAr5S0lm59y4B3bZoIHsIowgZ/nYIu/mt5AFCT/wm yREK3ZBDTSH5NX+IAlGQ+gycREF/Kp6hhEDAE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=xxBBiXVe+oR3BytNmNWhUaDfgAkB6scADaKHw/G5Z48=; b=aPg7pFk+iVwi79XUvBQN/uw7LjotoytXDbZ/IMhScIwbrQbD60Iwlx/Q883YjLjajB LUoIHLRjKDun209bcnO998xjXB6wQgyAWObTAAOLD7InfI8Rql8Dx9I6U07weAkpC5ZD sMbsi4YuhO6RznMnLCsa7TE7NLnAwwszRZNQTbqH8xR15LgpB+omxuYX0lwZ/7cowhfI gtTACHDjwjT32Sle4oRZYBXccX7g/zb1+Pal8Q/23pxvk7lb+VCS1q39jC/5bxBkNycy jL2l3dn06KLje5YnE2yu+M2E45poQwVtU5WuYewvJyKRvmJp9986AT1UeegxhqNCQw1F qtWQ==
Received: by with SMTP id a8mr1448684vdj.49.1350656991814; Fri, 19 Oct 2012 07:29:51 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 19 Oct 2012 07:29:31 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Tom Ritter <>
Date: Fri, 19 Oct 2012 10:29:31 -0400
Message-ID: <>
To: Chris Palmer <>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQkmWcTiEukT8s6J24Gl0EbRrPX41yoFs2/C/40HcLqeRXEkeI64EK6skWXvLyhX4QuhijMc
Cc: IETF WebSec WG <>
Subject: Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Oct 2012 14:29:53 -0000

On 18 October 2012 21:15, Chris Palmer <> wrote:
> I think it's reasonable enough. However I did add this:
> """The UA MUST note the pins if and only if it received the
> Public-Key-Pins response header field over an error-free TLS
> connection. The UAs MUST ignore Public-Key-Pins response header fields
> received on HTTP (non-HTTPS) connections and on HTTPS connections that
> are not error-free."""
> to (hopefully) resolve this:
>> Similarly, I wonder if there was some situation that could result in
>> an attacker-induced 'errored' TLS connection that still sent the
>> header, resulting in the data being discarded...
> Thoughts?

Sorry, but I think that introduces more confusion.  Point 1 includes a
criteria and a "Do Something if not Criteria" but the following
paragraph after the Criteria also includes a "Do Something if not
Criteria".  I would suggest moving the "do something" out of the first

I would suggest the following, which moves the 'do something' out of
criteria 1, clarifies that the discarding action only applies to
currently Pinned Hosts, and states explictly that when we say
"error-free TLS" this includes the validation in Section 2.4 if

The UA MUST observe these conditions when noting a host:

   o  The UA MUST note the pins if and only if it received the
      Public-Key-Pins response header field over an error-free TLS
      connection. If the host is a Pinned Host, this includes the
      validation added in Section 2.4

   o  The UA MUST note the pins if and only if the TLS connection was
      authenticated with a certificate chain containing at least one of
      the SPKI structures indicated by at least one of the given
      fingerprints.  (See Section 2.4.)

   o  The UA MUST note the pins if and only if the given set of pins
      contains at least one pin that does NOT refer to an SPKI in the
      certificate chain.  (That is, the host must set a Backup Pin; see
      Section 3.1.)

   If the Public-Key-Pins response header field does not meet all three
   of these criteria, the UA MUST NOT note the host as a Pinned Host.
   A Public-Key-Pins response header field that meets all these critera is
   known as a Valid Pinning Header.

   The UAs MUST ignore Public-Key-Pins response header fields received on
   connections that do not meet the first criteria. If the UA recives
   a Public-Key-Pins header from a Pinned Host that meets the first
   criteria, but not the following two, the UA MUST discard any previously
   set Pinning Metadata for that host in its non-volatile store.

>> 2.5: "Pin Validity Times"
>> I find the "current + current - initial" / "(b) the amount of time the
>> pin has been noted" item confusing, and am not sure what it means from
>> reading only the draft.  If I'm not the only one, it might be worth
>> clarifying.
> Yes, even after a lot of thought I am still undecided about this. I
> see several possible approaches:
> (a) simply have the validity time be the same as for HSTS;
> (b) the same as HSTS but with a 30-day maximum;
> (c) the current attempt to mirror TACK, except clarified and with examples; or
> (d) something else.
> Of these, I think I currently like (b) best. Thoughts?

I think A.  I believe (without evidence) there are institutions that
would eventually like to use this that have customers that work with
them on a quarterly or annual basis.  Likewise, I believe (without
evidence) that a institution who was risk adverse would mitigate that
risk by pinning to several large CA roots, not by saying "Oh well our
customers can't access us for the next 30 days, but it's only 30 days
who cares - but 60, that would be unacceptable!"

I do like TACK's notion of 'growing' out pins but only in a "That
sounds like a feature we're anticipating people wanting" way.  If
people actually hold off on deploying this because of that and that
alone, it SHOULD be possible to add a new directive, ignored by older
browsers who don't implement it.

Public-Key-Pins: max-age=600; grow-to=86400;

The spec should probably note that directives not understood should be
ignored, and not invalidate the header, to allow for future expansion.

> I think you mean "clears dynamic pins"?

Yes, dynamic pins.

> I don't consider the implicit tracking cookie problem to be solvable.
> I think EFF's Panopticlick conclusively shows that it cannot be
> solved.
> ...
> I suppose we could press the Safe Browsing list into service for this
> (and data and API for that are open), but it's a stretch. SB is about
> malware and phishing, which is a different thing than implicit
> tracking.

I was actually saying "Chrome shouldn't ship preloaded pins for
Marketing Firms, because if a MF sends Pins to a user in Incognito
Mode, then the user closes Incognito Mode - MF can learn that a user
is a repeat visitor even though they visited in Incognito Mode."  But
AFAICT that would be all the information a Marketing Firm would be
able to learn - binary visited or not.

BUT: Even if UAs did not ship pins for Marketing Firms, it wouldn't
matter because an attacker could use Cross Origin Img Loads with a
stolen certificate to learn the same amount of information (whether a
user visited in Incognito mode) about a valid, non-marketing site
(e.g. Abuse Counseling site).

> It could at best be a "UAs MAY choose to ignore HSTS and pinning
> metadata for certain sites... a mechanism to do so is beyond the scope
> of this I-D..." thing.

I recant, I don't think this is necessary, because the above is not
solvable in the technical constraints and Incognito Mode clears pins.