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

Tom Ritter <> Tue, 26 August 2014 21:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6FB901A8876 for <>; Tue, 26 Aug 2014 14:07:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.021
X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1-L-Ch_8iyhU for <>; Tue, 26 Aug 2014 14:07:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1DD391A8866 for <>; Tue, 26 Aug 2014 14:07:15 -0700 (PDT)
Received: by with SMTP id uq10so5208599igb.14 for <>; Tue, 26 Aug 2014 14:07:14 -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=Tzq3stZtDNyPpkGtFcbv/09RL7K1RxzIdplqdnmt3lk=; b=5LxnOlBJ4Q+SLqXRzX7gBpN+vdRJJL9bsmqtSw9fO1FGZkLyO1mC+APbSu5I7m+jxr QJIs8HN64SPeGy7wvQARvIdNnC1Kkv9VZFI3pbftLiKFeKcsYTu1G/8R79mVpZGI66uo fn6wZLBiSEJzMCyzew6PkoUnlxBrikcm3CLjM=
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:from:date :message-id:subject:to:cc:content-type; bh=Tzq3stZtDNyPpkGtFcbv/09RL7K1RxzIdplqdnmt3lk=; b=NEmO2W5WCVSw17YyeAj1T9u+MBV4n0GpWyBmdyhzWAkvewqYpeN3O/MyklujLVCY4U Ss4dhu4qPWP5/xXtnA6xIpNX71B5D+iHOZwDrHerhiNp2okkguhJTxOik6waWyvPrC4y f/1VYvn6+KvrnTVq9eVjhE+Una3/RL3JzeUkayMpO10oD4QFYxMow/0o8jeXzZxqAnpP FGf7DYplO7ULYLQzPu4QRuUdF2/ErrOdS2r2myRJtipJeqm/Jb1b5+V51DO01gcGPcA8 sTkjsdjzLMrTs6voxNnNn8+GxIS0NlEt1Am/AiMJIzNauzExQK1oF9YQ02T0Apg6k0Dn nz1w==
X-Gm-Message-State: ALoCoQmMYLOoZaNTLIl0kET6S2s70DhaegZe8f1nstDvM4qOJcwhn99WnDrk0SJ8HC66sNjMKrEZ
X-Received: by with SMTP id gs18mr2821475icb.96.1409087234524; Tue, 26 Aug 2014 14:07:14 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 26 Aug 2014 14:06:54 -0700 (PDT)
In-Reply-To: <>
References: <BAY169-DS62B5941BF0A9024964BB0AEEE0@phx.gbl> <> <BAY169-DS45F1C5036AB09CA44D0BC7AEDF0@phx.gbl> <> <> <> <>
From: Tom Ritter <>
Date: Tue, 26 Aug 2014 16:06:54 -0500
Message-ID: <>
To: Chris Palmer <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: "" <>, Eric Lawrence <>, IETF WebSec WG <>, Ryan Sleevi <>
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: Tue, 26 Aug 2014 21:07:17 -0000

On 26 August 2014 15:51, Chris Palmer <> wrote:
>> Requiring PKP-RO to be on every load would allow an attacker
>> to strip the header on the connections they MITM.
> Only if The Alice Foundation did not also use a regular PKP header.


>> Letting it be cached
>> allows an organization to put a max-age of 45 days on it, without the
>> risk of bricking their site if they aren't administratively competent.
>> Obviously an attacker can also block the reports from being sent, but
>> I'm hoping that the clause "In any case of report failure, the UA MAY
>> attempt to re-send the report later" will be considered in this case,
>> and that UAs will make an attempt at getting potentially blocked
>> reports out at a later date.
> Yeah, sort of. But don't think of PKP-RO as a defense against attacks,
> even if it might sometimes have that secondary benefit. It is
> primarily a debugging aid for The Alice Foundation and BobCorp to get
> PKP working. ("What all Trents do we need to trust, anyway?")

I'm not going to put words in your mouth, because different authors
have different opinions about things, but I will quote from another:

> Ryan Sleevi wrote (
>> I wrote:
>> 1. A large site that is commonly proxies by corporate and malicious
>> actors wishes to monitor how common this is done.  They place
>> javascript bindings in their code to view the user's certificate and
>> report the observed value.
>> Note this use case has already been performed by Facebook, who had to
>> resort to Flash to do so, because javascript did not provide the
>> functionality.
>Use report-uri with HPKP, in report-only mode

I don't consider PKP-RO as a defense, but as an attempt at detection
of attacks, with no risk of breaking your site.  It is extraordinarily
useful to be notified of attacks against your users, even if they are
not prevented. They help you understand where you should invest time
and money.

The foot-gun potential is very high with HPKP, we all know that.  It's
high enough to the point that many organizations, who have someone
maintaining a website part time (or outsource it) may forgoe PKP
entirely because it makes them nervous - but they would be happy to
deploy a no-risk PKP-RO.  But the benefit of doing so if it is not
being cached is extraordinarily low, to the point it's probably not
worth doing.