Re: [websec] draft-ietf-websec-key-pinning

Trevor Perrin <> Thu, 04 September 2014 23:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1A36E1A02BA for <>; Thu, 4 Sep 2014 16:53:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 861QIVDpKdhD for <>; Thu, 4 Sep 2014 16:53:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 947E21A02AC for <>; Thu, 4 Sep 2014 16:53:49 -0700 (PDT)
Received: by with SMTP id h15so2127179igd.8 for <>; Thu, 04 Sep 2014 16:53:48 -0700 (PDT)
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=vNF+2RTVFuurnZL3h2zhu6UMW0oie1pkwDZxF2mlc1o=; b=m8EQ4USMswELkeBOFCNBuJx4yaqjDWAIUEja0d9sFX5uTH34TOCLpx2+UQoTsh3Pnc EaDDlw5ry0+tlASLoxp6n/3vUkTjd/RSNpktADqD36Fn0lTl7Cwpd3Dyruhc6DyKtCuE mK7fWL7NfgF14Jkvx0nY34MRlwOoByNcoNQo3Xg4b4SuOsZR33qZULlgZWzM9taHSDxh 4f9HwroqGzMn+ycxpgKnc36eyPkvh3T1pEc7fmgAQJpK5/dvsdxs1qjDU1aIH0029kV5 ajzLAJrteLqXYY/T8zEDNacKSkGZsVmASmJ0ombEkYBNkWg2SFd+aAt5cH7L5xFqba+h j1cg==
X-Gm-Message-State: ALoCoQnv1vKTPDDhb0oI+7YZhPFulprUPd+l80JnoJhDVKEtfz77PQIGX7GfNAjod2OK8HQ9fP9A
MIME-Version: 1.0
X-Received: by with SMTP id lk20mr9863599icc.17.1409874828817; Thu, 04 Sep 2014 16:53:48 -0700 (PDT)
Received: by with HTTP; Thu, 4 Sep 2014 16:53:48 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <BAY169-DS311951F23960F4605A0CB0AEDA0@phx.gbl> <> <BAY169-DS421419C50B5700132829BBAEDA0@phx.gbl> <> <>
Date: Thu, 04 Sep 2014 16:53:48 -0700
Message-ID: <>
From: Trevor Perrin <>
To: Ryan Sleevi <>
Content-Type: text/plain; charset="UTF-8"
Cc: draft-ietf-websec-key-pinning <>, IETF WebSec WG <>
Subject: Re: [websec] draft-ietf-websec-key-pinning
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: Thu, 04 Sep 2014 23:53:51 -0000

On Thu, Sep 4, 2014 at 4:09 PM, Ryan Sleevi <> wrote:
> On Thu, Sep 4, 2014 at 4:02 PM, Trevor Perrin <> wrote:
>> I agree with Eric and Joe that the current definition of PKP-RO is not
>> that useful and potentially surprising to deployers.
>> Ryan argues that storing PKP-RO is dangerous because a TLS MITM who
>> could set pins for a lot of clients for a lot of sites could flood a
>> victim with reports.
>> Couldn't the MITM also set PKP pins with report-uri, or set cached
>> redirects or other cached resources to generate traffic toward a
>> victim?
> Yes, and that's a user visible effect, rather than transparent.

Hmm, there's nothing clever that can be done with cached javascript or
html to also generate silent traffic toward a victim?

> It also
> requires that a connection be validated first, whereas the very definition
> of PKP-RO is that you send it when a connection is not validated.

I'd expect stored PKP-RO to follow the same rules as PKP and be stored
only if it meets the bullet points in 2.5 (error-free TLS connection,
backup pins, etc.).

It would make sense for any report-uri header (PKP or PKP-RO) that
fails the 2.5 checks, or has some other invalid syntax (eg bad
base64), to *also* generate a different sort of report and not be

Would it be reasonable to add a reporting message for 2.5 failure or
syntax failure?  Otherwise, when asserting a report-uri pin you can't
distinguish pin-not-stored errors from

>> Ryan argues PKP-RO is worse because it's "conceptually and practically
>> silent to the user".  But once the browser has sent junk traffic to a
>> victim, I don't really see how seeing how displaying a pinning error
>> makes things better.
> First, the attacker can only mount the hostile attack after having first
> established a good connection.

Debateable per above.

> PKP-RO allows an attacker to perpetually
> mount a hostile attack.
> Second, the presence of a pinning error is an inherently rate-limiting
> factor to the user experience. You're not going to be able to trigger 100
> reports if you're causing the user 100 error pages.

Rate-limiting is already proposed:
UAs SHOULD limit the rate at which they send reports.  For example,
   it is unnecessary to send the same report to the same report-uri more
   than once per distinct set of declared Pins.

Wouldn't that take care of it?

> Third, it seems like you're arguing for removing report-uri altogether,
> given the privacy and DoS risks identified. That is, the more that  you
> establish RO is similar to PKP in level of what an attacker can do, the more
> it argues for removing report-URI entirely.

Dunno.  I'm still trying to understand these risks, whether they're
really different for PKP-RO vs PKP, and for HPKP versus other web