Re: [websec] Kathleen Moriarty's Discuss on draft-ietf-websec-key-pinning-19: (with DISCUSS and COMMENT)

Ryan Sleevi <> Mon, 25 August 2014 05:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D4C0B1A8A4B for <>; Sun, 24 Aug 2014 22:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.147
X-Spam-Status: No, score=-0.147 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N-gg63Tpvge8 for <>; Sun, 24 Aug 2014 22:44:04 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2EC491A8A57 for <>; Sun, 24 Aug 2014 22:44:04 -0700 (PDT)
Received: by with SMTP id hq11so14591651vcb.38 for <>; Sun, 24 Aug 2014 22:44:03 -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; bh=/Kv9YfvFf5Dtvl9AJjHMtanTfiMvKwwC1B4tNEIl2bM=; b=bHNXY/f+vyzSg8omEEMs+25nU052fNebKbt5lvNjXkdcND+R0G71gaQJG7AJUj1tUk 8F1gYwqenpYXG+EeUyI6kSgbv9haToRBun7WdqB9shu+VPDLHwlDbnuEGI6tnoIxD65F lAJEmKHmiMjSztfMmeJjFvpcpMHr5Js7esC6+nDsYP3b4q1Bw5c28VERuvPq9fhvW0XO hHmwlx/SJExI9kU/fF6zixiz+g08v7Iwir//rruYFAYl8tZMxFHDFBvCEkWLi5hTHinm rVRSge0DYj2/0aVUdoCpN0rJE405vquEWbi3mmBcT96MYx9syLYwDf0VShcyMxDkbZDv PM3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/Kv9YfvFf5Dtvl9AJjHMtanTfiMvKwwC1B4tNEIl2bM=; b=bRJB2L3iO/4jk/LlsjNaiNYWzl6b/ATdzeeLIEpKmBR5Ra5+Vlphjc3+Jfagc5AAt/ Jr8tp5tOgOrBc2AmZrW94ClQ3dNlzOfOjEn++K9mFHoCWMsxOUteQ2EomYsj2QKqV+lc tFuHW3cRvUJftHasn6t2Cr/PiXfxwu63rwP5IDYVRruyv5n/WHn4spFioAM90sYcfJ3v zaqtHt5xc7u2w/NSR3iD7bXMnhuwUg3stylum+HAT1Fh/FsazlE+EBnrPTP3W6lRyhhe Ipf8wlGglHDGNYTgUNOiiMm3VPNGflwTs1b3ZuIG65+Z5XGHp0DUhSQ94iFrG43Gjyqj Qgmg==
X-Gm-Message-State: ALoCoQngsTHUYgs9yD1JErHZLxqh51bsmYdC4Hst7bMqlbLeqnnqVx9YkYXjTlDcPsSkIrV30taX
MIME-Version: 1.0
X-Received: by with SMTP id ry8mr3184701vdc.64.1408945443186; Sun, 24 Aug 2014 22:44:03 -0700 (PDT)
Received: by with HTTP; Sun, 24 Aug 2014 22:44:02 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Sun, 24 Aug 2014 22:44:02 -0700
Message-ID: <>
From: Ryan Sleevi <>
To: Kathleen Moriarty <>
Content-Type: multipart/alternative; boundary="089e011765b9a6459605016dac3e"
X-Mailman-Approved-At: Mon, 25 Aug 2014 01:24:12 -0700
Cc:, "<>" <>, The IESG <>,
Subject: Re: [websec] Kathleen Moriarty's Discuss on draft-ietf-websec-key-pinning-19: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.15
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: Mon, 25 Aug 2014 05:44:07 -0000

On Wed, Aug 6, 2014 at 8:15 PM, Kathleen Moriarty <> wrote:

> Kathleen Moriarty has entered the following ballot position for
> draft-ietf-websec-key-pinning-19: Discuss
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Overall the draft is very good, thank you for writing it.  I just wanted
> to discuss some of the security/privacy considerations and see if we
> could improve the language and make sure the set of concerns are clear.
> The privacy consideration section reads more like possible attack
> scenarios that would fit into the security considerations.  What privacy
> related concerns result from these attacks?  Having that spelled out to
> differentiate the risks as privacy only would be helpful (if appropriate)
> or moving this into the security consideration section *IF* it is more
> generically applicable.  If I am missing something and this is only
> privacy related, it would be good to understand that in this discussion.
>  Adding some text on how these attacks could be used to expose privacy
> related information would be helpful too.

The first paragraph spells out precisely why this is listed as a privacy

   Hosts can use HSTS or HPKP as a "super-cookie", by setting distinct
   policies for a number of subdomains.  For example, assume
   wishes to track distinct UAs without explicitly setting a cookie, or
   if a previously-set cookie is deleted from the UA's cookie store.

Neither of these attacks undermine the protections afforded by HPKP.
Indeed, they exist precisely BECAUSE of HPKP offering a new means of web
storage. Essentially, all storage mechanisms introduced when dealing with
sites - whether it be cookies, new APIs like IndexedDB, exposure of
persistent storage such as cryptographic keys, or, as in both HSTS and
HPKP, remembering data about a previously visited site - represent new and
potential ways to uniquely identify a user, which the two examples spell

> For the first example, it seems it is the possibility that a report goes
> outside out the intended scope is the concern.  The mitigation seems to
> be provided in the last sentence of #4, but couldn't this be other
> information leakage and not just privacy?  Let me know if I am missing
> something that explains why this is privacy specific.

I'm not sure how that was reached, as the description of the risk was
explicitly enumerated

   and the ability to pin arbitrary identifiers to distinguish UAs.

This is also reiterated in the #2 and #3.

The same applies to the second example, which hopefully the above
explanation is sufficient to demonstrate how the spec already highlights,
in several means, how this is a privacy issue (distinguishing the user
independent of cookies, aka a "super-cookie")

> In #3 of the second example, the last sentence includes the following
> clause:
>           and giving some UAs no
>           Valid Pinning Header for other subdomains (causing subsequent
>           requests for to succeed).
> Does this mean that these subdomains are succeeding when they should
> fail?  It might just be me, but that is not clear in the text (or if they
> are supposed to succeed).  It sounds like they are not supposed to
> succeed and this is the security issue.  How is this privacy specific?
> Again, this may just be me, but an explanation would be helpful.

Do the above references to the existing portions of the spec make this

As noted above, the attack is about identifying and tracking users through
means other than cookies. Such attacks are also known as "super-cookies",
which is the term explicitly used in the introduction of these attacks.

As noted, the attacker is the site serving the headers itself, which is why
it's a privacy issue.

> In the last sentence of the privacy considerations section, what is meant
> by the description "forensic attacker"?  I find this term confusing.  Was
> this intended to mean that techniques used in forensic analysis could be
> used by an attacker to discern information that could be of interest?  If
> that's the case, I think it would be clearer to the reader if that were
> stated instead.

This was in response to Alissa Cooper's YES vote, in which a threat model
of an attacker with physical access to the machine attempts to recover
state of the user's browsing history, which the UA had otherwise cleared.

Per Eric Lawrence's feedback, this third section will be reworked into it's
own privacy consideration bullet, and hopefully you'll find the
clarification suitable.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> I agree with Richard's comment that the document is well written and an
> important document, thank you for writing it.  The style changed a little
> toward the end and I had some trouble with long sentences in the security
> & privacy considerations sections.  This should be easy enough to fix and
> may be done with the RFC editor anyway.
> To Richard's point on operational concerns versus security concerns, are
> there explicit security attacks that could occur with the max-age
> variations described?
> In 4.2, I can't see this being more than an operational concern since it
> fails when overlapping pin sets are not used.  Are we missing a gap that
> leads to a security concern?

I suppose it depends on your threat model and how you view domain authority.

In the example given, is bypassing the pins set for, depending on timing. That is, if
is visited first, then MUST be
equal-to-or-a-subset-of the pins for, by virtue of the known
pinned host evaluation.

Thus if wishes to administer pins for their domain (and all
subdomains), it's necessary for them to prevent subdomains from setting the

Now, you can see this as an operational concern if you view the
and as the same administrative entity, but that's
sometimes not the case (e.g. shared hosting sites like Amazon AWS, GitHub's
pages, or Google AppEngine)

> 4.3 makes sense to me as a security concern that drives operational
> practices.