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

Joseph Bonneau <> Tue, 26 August 2014 22:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C580E1A0041 for <>; Tue, 26 Aug 2014 15:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Sz6csXodFwQn for <>; Tue, 26 Aug 2014 15:45:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E91F11A0030 for <>; Tue, 26 Aug 2014 15:45:07 -0700 (PDT)
Received: by with SMTP id q200so12004154ykb.40 for <>; Tue, 26 Aug 2014 15:45:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=hDhl1rL/Xx4a10eC3mTglxxODxp6F9iWh9jZDRTjjSY=; b=lYQX83rkbTIKbn4IZF70uVuUuvi+z9Pz4pdWSExMxBTLAXHnqwSXpLim0ZPuqtW+ms UL9YukTBSlwMN1xE8E1RcBLeS+oChFVMa0QUujO+RV4AWPIDKG95QN88MJNPU8yZYv7W ojkMM0Dz6fZhnZQulQh4nCvu08vo7PUiSfryd7lCSn1TryCkz9GifG3VoOKsOZZnsS2F 9fCaIqPvOOMsM52R0/2ZO3/N2w95tBokR49fKXjrHtg/+AXO9i90K3vjyoyZORnYJvUw 1pu72w2hdNmllXRWBAlbfXVtsAb58FdxhN/BDy2kObHqEoWaKjMvgYrGdCmttumPpfF4 ZgMg==
X-Received: by with SMTP id kx5mr447643vdb.40.1409093107240; Tue, 26 Aug 2014 15:45:07 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 26 Aug 2014 15:44:46 -0700 (PDT)
In-Reply-To: <>
References: <BAY169-DS62B5941BF0A9024964BB0AEEE0@phx.gbl> <> <BAY169-DS45F1C5036AB09CA44D0BC7AEDF0@phx.gbl> <> <> <> <> <BAY169-DS45D73636AA204DEEABC876AEDC0@phx.gbl> <> <> <> <>
From: Joseph Bonneau <>
Date: Tue, 26 Aug 2014 18:44:46 -0400
Message-ID: <>
To: Chris Palmer <>
Content-Type: multipart/alternative; boundary="047d7bdc99aa1cd4ed0501900e0f"
Cc: "" <>, Eric Lawrence <>, Ryan Sleevi <>, 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: Tue, 26 Aug 2014 22:45:09 -0000

On Tue, Aug 26, 2014 at 6:10 PM, Chris Palmer <> wrote:

> On Tue, Aug 26, 2014 at 2:42 PM, Tom Ritter <> wrote:
> > This is especially true if includeSubdomains is enabled. It'd be
> > common for that directive to apply to hosts that the -RO header would
> > not be included on. In PKP-RO, it would not be applied to them; in PKP
> > it would.
> OK, so, what do you want?
> Is it even possible for me to write text you would accept?

The answer may be "no" here which would suggest dropping PKP-RO completely
as an alternative way forward. Taking a step back, this thread features two
sides arguing that this feature is (largely) useless for what the other
side wants it for (testing vs. security).

As pointed out, the current version is not nearly sufficient for testing a
site's PKP-readiness due to subdomains and (potentially) load-balancing a
domain onto servers with different keys (some of which may not be in the
pin set and not set PKP-RO and be missed by setting the header on other
servers). Testing with -RO is surely better than no testing at all, but it
seems most domains would need to do more extensive testing manually by
crawling/viewing network traffic/etc. at which point they'd gain the
benefit of -RO testing anyways.

Maybe there is some benefit for quick tests to see what certs UAs are
actually receiving, which it was pointed out Facebook used Flash to achieve
(I know of at least two other academic research efforts that have used the
same approach). But if this is the goal, PKP-RO is pretty limited compared
to adding something to JS or WebCrypto which would just ping back with the
exact cert chain received. This use case seems best addressed elsewhere
rather than bolted onto this spec.

Hence, given the concern that this spec is already bloated, I would
advocate we seriously consider dropping -RO mode completely.