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

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4FECD1A01CB for <>; Thu, 4 Sep 2014 16:03:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.722
X-Spam-Status: No, score=0.722 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vQXsnHu4i0dd for <>; Thu, 4 Sep 2014 16:02:59 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58B771A01CA for <>; Thu, 4 Sep 2014 16:02:59 -0700 (PDT)
Received: by with SMTP id at20so12772577iec.33 for <>; Thu, 04 Sep 2014 16:02:57 -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:content-type:content-transfer-encoding; bh=hPXtWhPkvlsMMGRTHVuoHI+LJkeHDH3IkpMI9z1Snwc=; b=EbFPqgcnaxCKrvOQHBLKYvZ3peyJOKYGb5mGXBCcU0f85Zp3fZ6zdyAj1u4wiDnxWT YA7riOu0iu6C+H/8wFPAdTWREGL9ogIxTUHkZ9PgvxJlRL9C7gBKmwi0+eyass4P/u5U NQVHrjf3RkKZX+/4N9QPqwQqLPz/2/GdI0C1DLzm56zO5OfYo19z6T6yE/8Khoru4DHW S8n15snvUS1OxWeFvBrtiV+riCv2MkW/OwRdp6KlbVognVCc/HBRorp5OjnLNS7tu3Af YtQKGtevagEanVIY18o8gmRJI+LEy+fzf0XjyTo3D44AZoPm0khICEGg5FNAnWAkTvlY fZ+g==
X-Gm-Message-State: ALoCoQlnckCEAU+kl8xIZSJKWYS7rEQySKrO1JOkvxQqSy9hkjuGpo8NCHASpPi0FNYD6u+XCNy9
MIME-Version: 1.0
X-Received: by with SMTP id y6mr9527894icn.28.1409871777599; Thu, 04 Sep 2014 16:02:57 -0700 (PDT)
Received: by with HTTP; Thu, 4 Sep 2014 16:02:57 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <BAY169-DS421419C50B5700132829BBAEDA0@phx.gbl>
References: <> <BAY169-DS311951F23960F4605A0CB0AEDA0@phx.gbl> <> <BAY169-DS421419C50B5700132829BBAEDA0@phx.gbl>
Date: Thu, 04 Sep 2014 16:02:57 -0700
Message-ID: <>
From: Trevor Perrin <>
To: draft-ietf-websec-key-pinning <>, IETF WebSec WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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:03:02 -0000

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

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.


On Thu, Aug 28, 2014 at 9:13 AM, Eric Lawrence <> wrote:
>> testing with PKP-RO may
>> be fine before first deploying PKP, but it doesn’t help you where it’s
>> dangerous -
>> when it’s time to change certificates.
> In addition to raising confidence before you first deploy, PKP-RO helps when
> you wish to retire a pinned SPKI.
> For instance:
>   0. Acme Corp has a secure website; they’re using PKP with
> includeSubdomains.
>   1. Acme Corp currently buys its certs from Verisign and uses PKP to pin
> the Verisign intermediate SPKI.
>   2. Next year, Acme Corp decides that they want to buy GoDaddy certs
> instead. They update their PKP header to add the GoDaddy intermediate’s SPKI
> to the list.
>   3. Because Acme Corp is a huge enterprise, they don’t know if some
> business unit (e.g. didn’t get the memo about the
> move to GoDaddy and may still be using a Verisign cert. So, in addition to
> the updated PKP header, they ALSO send a PKP-RO header that specifies *only*
> the GoDaddy SPKI and watch for any reporting failures.
>   4. After an appropriate period, Acme concludes that they are safe in
> replacing the PKP set of SPKIs with the set they prototyped in PKP-RO. They
> do so and remove the PKP-RO header.
> -Eric
> *An aside vis-à-vis the plausibility of #3, a site not knowing about its own
> subdomains: I recently spoke to a site (“”) that wasn’t using
> includeSubdomains on their HSTS header. I asked why not, since all of the
> company’s public websites were HTTPS. It turns out that they can’t use
> includeSubdomains because their private Intranet uses internally-mapped
> domains subordinate to their public domain name suffix. So, while
> “” isn’t publicly reachable, browsers don’t know or care, and
> HSTS+includeSubdomains will fail any insecure connection for the employees
> inside the company.
> A similar challenge will face any such companies when they try to use PKP
> with includeSubdomains.
> From: Yoav Nir
> Sent: Thursday, August 28, 2014 9:59 AM
> To: Eric Lawrence
> Cc: Ryan Sleevi ; Tom Ritter ; draft-ietf-websec-key-pinning ;
> Subject: Re: [websec] draft-ietf-websec-key-pinning
> Hi Eric
> Part of the issue is that PKP (and PKP-RO) follow the lead of other headers
> such as CSP that also have report-only alternatives, but PKP is inherently
> different.
> CSP has directives that relate to the content delivered, so if CSP has a
> directive that says the resource cannot be displayed behind a transparent
> floating frame, the content will not be displayed. If it’s CSP-RO instead of
> CSP, the content is displayed, but a report is also sent. That makes sense,
> and if you see that the CSP-RO header causes reports, you can adjust it.
> Once you move to CSP, you’re fine as long as the content does not change,
> and even if it does change, you can test it first with a test server.
> For PKP it’s different. The thing that changes is the certificate presented
> to the client. You can’t test the new certificate on a side server, at least
> not in a way that will fill you with confidence. And because of the way
> certificates are used, there is no such thing as a static structure to the
> site. You have to change the certificate (and usually the key) every year,
> so testing with PKP-RO may be fine before first deploying PKP, but it
> doesn’t help you where it’s dangerous - when it’s time to change
> certificates.
> This leads some people around here to conclude that PKP-RO is not useful.
> Yoav
> On Aug 28, 2014, at 5:26 PM, Eric Lawrence <> wrote:
> I’ll take one last tilt at this, because I think this spec is quite
> important and folks aren’t actually very far apart on this.
> To start, I want to reiterate that Draft #20 was the first time I got
> involved in PKP, so my perspective comes from that draft and not any other
> conversations, tribal knowledge, meetings, etc, that others in the group may
> have been a part of.
> Here’s how I *thought* Draft #20 specified things to work:
>   1> PKP and PKP-RO are equivalent in every way except that PKP mismatch
> triggers a Report *and* fails the connection, while PKP-RO mismatch only
> triggers a Report. That’s why PKP-RO is named “Public Key Pins Report Only”
> and not “Sorta Like Public Key Pins But Does Not Break Connections And Does
>   2> Site administrators should use PKP-RO to prototype a policy to be later
> deployed PKP. They use PKP-RO first to generate confidence that they will
> not be self-inflicting any broad denial-of-service when enabling PKP.
>   3> When PKP and PKP-RO headers are initially encountered (pins not
> previously stored), a failure to match the specified policy triggers a
> Report. The mismatched policy is NOT stored, which blocks the DOS bomb
> attack Ryan mentions below.
>   4> PKP and PKP-RO only exist as different headers because it allows a site
> to have one policy in force and also prototype proposed policy changes.
> This design made perfect sense to me, and my feedback on the draft was
> primarily intended to clarify the language around this design.
> Instead, it appears that PKP-RO works dramatically differently than PKP, in
> ways that I believe are entirely non-obvious to implementers who only read
> the draft. While I believe it would be possible to editorially change the
> language to make PKP-RO’s different behavior, to me, that approach only
> seems to be codifying a more confusing, less useful design, and would
> require more work on the part of the authors.
> I don’t believe there are any privacy or security implications in allowing
> PKP-RO to behave like PKP except that it’s “Report Only.” Any privacy or
> security implications in PKP-RO are shared by PKP.
> -Eric Lawrence
> _______________________________________________
> websec mailing list