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

Chris Palmer <> Fri, 19 October 2012 01:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71E1121F852C for <>; Thu, 18 Oct 2012 18:15:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E1SC-hNXPI2l for <>; Thu, 18 Oct 2012 18:15:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2FC3421F84FE for <>; Thu, 18 Oct 2012 18:15:35 -0700 (PDT)
Received: by with SMTP id k13so20547lbo.31 for <>; Thu, 18 Oct 2012 18:15:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=e7RheKouxK3UaRxz2OOeJtvfp0CHz35/HBdRAEGkZxI=; b=kxEI8TGzcCJ4lc0rwPJCVJcMjgoZMRzFnBO4o0NHvLrqpwLdLxxYlZfHjcXmiKKde8 /vgRG6rusOybyedFG6jvHNpeS5wqIKA2D5cg1vzU2qnhdCGv1K5MD8ke+gn69bNVjgUZ fqu7/vRf3SqepdNnJZz7FQqpIN6Yq8yL3TqV0wJvfG7zPIutC+LXjyyoYzgyKk1a2fvB egOnr9Pm7MGd6U4mVyu1cafVc3Kts1z6IJsvKkR+06Mo10BXtRLfQBbiIjY5oQj0S7dV bwBBg3R6gRbBm49GpUS5dw12SUe7oP+cr9WIH15Pd4kw1PeJAwjMFDXy3b+9VkblImqC Iv5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=e7RheKouxK3UaRxz2OOeJtvfp0CHz35/HBdRAEGkZxI=; b=IX2enKOnNsSMKVNmxSxDGQS9UMQvaIqZV8hsDUfDyK1g3bVsO3kjOU4AlKL3AwFqtg ONMHfa0MAAI2yuxLRGL0LFhMaZellz6+5TBEfqUqlTUG2L6uY5eAhjiCjoJTLTLnss+B 5ZRcXT0S/sC0JntOFVlxjYhUs9G+H2HHzud/jcgGTh+GFy76pird/1ggWaOzGjYIj4+6 yDisBhMjKnepMzftNCbD+aXNtU+js2O7Up1bCVkP8Fs+rWJQEMNWBBoHf0yXP8ZPWOM4 2v6QZvKBm5h1fqw2Ndz1SZmbyo/XR1fxNw0syT7lBmyw1BJMnQ7FVUcuEftDIB2typqF koXg==
MIME-Version: 1.0
Received: by with SMTP id lo11mr20158193lab.3.1350609334683; Thu, 18 Oct 2012 18:15:34 -0700 (PDT)
Received: by with HTTP; Thu, 18 Oct 2012 18:15:34 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Thu, 18 Oct 2012 18:15:34 -0700
Message-ID: <>
From: Chris Palmer <>
To: Tom Ritter <>
Content-Type: text/plain; charset="UTF-8"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQn/xs46gxdnyaOLk8wIfIacja0d55IViNT52Y2Zd2Gv/qXzDBGFye+l0XtCcAtkSaGEoQz1TFBgE+LxHwx5XGgTdAkdYtxA6OHDT3rcOkQS8bqIflU7VEMqZGIi4Jo3jEsOrm1nc5JcpSxbcpMNWxNA37ziSfYlt0FZ7mmLIPyHelw603lC3QbKSi7tVeLN7eMAR35P
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 01:15:37 -0000

On Wed, Oct 17, 2012 at 7:23 AM, Tom Ritter <> wrote:

> Section 2.3 "Noting Pins":
> I wonder if it is worth moving "The UAs MUST ignore Public-Key-Pins
> response header fields received on HTTP (non-HTTPS) connections."
> outside the criteria to be unambiguous that a client should not
> "discard any previously set Pinning Metadata" if it receives the
> header over HTTP.  Or if it's reasonable enough to assume no one would
> get confused.

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...


> Section 2.4: "Validating Pinned Connections":
>    For the purposes of Pin Validation, the UA MUST ignore
>    certificates who SPKI cannot be taken in isolation and superfluous
>    certificates in the chain that do not form part of the validating
>    chain.
> I know I just modified this, but the second phrase just hit me.
> Because path construction is non-standard, could a client wind up in a
> situation where the site pinned to CA_Alice, with the intended path
> CA_Alice -> CA_Bob -> Intermediate -> Leaf; but because CA_Bob was
> trusted, the ultimate validating chain was simply CA_Bob ->
> Intermediate -> Leaf?  I'm not sure what the right way to counteract
> that would be...

Yes, Ryan raised this hilarious point to me a while back, and now I
see he has responded to your question here on the list.

So, it's a strong motivating factor for a report-only mode. I've
created an issue tracker entry and a discussion thread for that.

> 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?

> 2.6.  "Interactions With Preloaded Pin Lists"
> If closing private browsing mode or clearing saved data also clears
> preloaded pins (and I think it should),

I think you mean "clears dynamic pins"? In Chromium's Incognito, any
accrued dynamic pins will be lost when you close your last Incognito
window. (If not, that is a bug and you can assign it to Also, in Chromium, when you clear browsing
history, chrome://chrome/settings/clearBrowserData, *and you select
"from the beginning of time"* (or presumably any time that predates
when your HSTS data is from), your HSTS metadata (e.g.
~/.config/chromium/Default/TransportSecurity) is indeed wiped clean.
That was true last time I checked, on 7 May 2012. Again, if you find
otherwise, assign me a bug.

> this would cause a revert to
> the preloaded pins, which may break sites.  A workaround may be to
> disable a preloaded pin if a new pin is seen, and keep that disabled
> even after the saved data wipe/private browsing mode close.

Good point. I'll add a note to that effect and ship it in the next draft.

> To prevent using this as a backdoor into tracking,

I don't consider the implicit tracking cookie problem to be solvable.
I think EFF's Panopticlick conclusively shows that it cannot be
solved. Tracking with HSTS and HPKP metadata would be a notably noisy
and inefficient way to implicitly track people; much "better" methods
exist now and always will. See just as a
random example...

> the preloaded pins
> should be sanity checked for "Is this organization likely to abuse the
> feature."

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

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.

> Again, excited about this - thanks for the work.

Thank you for all your help!