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

Tom Ritter <> Tue, 26 August 2014 20:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F10971A8844 for <>; Tue, 26 Aug 2014 13:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Az3ewrUWVQkV for <>; Tue, 26 Aug 2014 13:34:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 319F61A02F9 for <>; Tue, 26 Aug 2014 13:34:11 -0700 (PDT)
Received: by with SMTP id h18so5126181igc.12 for <>; Tue, 26 Aug 2014 13:34:10 -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=n6x6otjO8bLoGindwyptSGsKL1iROZtmz0rr+KUL7+U=; b=zjNCgSdyGgrOi72WtROaU0I/auSYkv/kBRBLpZ9QFgHs4jG/av2OVT9uS7VKFqzk9v bdgdxrhqtkuckHlcRA+gtQTJ9re/7frhue/WXcwsBKQjKznDc4/uABNxoDniGCbEU24u Jhna7wm9tMEjrBjsOotWk9qOXUSm4jJDmAHUE=
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=n6x6otjO8bLoGindwyptSGsKL1iROZtmz0rr+KUL7+U=; b=DU2HmtiBtW/2QwZvs+Fry+4lt7TPa6Ue1aJTCNj0EIfiCMCxlAzmIzUYPu4vh9/QxO 5yiWCN+j5xe7Z+CjDhowWIYskbyRZOUJ9SZvibDLDBc6erDdiXMkSQ8dMgRf36OOGd3l PhA8AoDsVB2BvJWvzFOwThF/vciT5ftJet3hDIWPnnGWM9TSMoMZVJdIc5/37wJS5m2u Es1aQ7//JEhUVoIaCBbYv9rMgEk8EIL/le9xtu2bWZEm3JLiiNn5AiQ5ns4ct0+HSt31 Yx2gxIW7MRXF30s2pvxdON1/rV2X0uNIiUNdROCj1yh6QBcryxiNY687U96rCSIxBqde g1JA==
X-Gm-Message-State: ALoCoQmEJfXKlK21IGEUynTlkLOYp8JgONd0XDLZ0E9CavwYschXloxiQ+NX31wCKOYaMpM3q9vJ
X-Received: by with SMTP id kd10mr24841946igb.5.1409085250649; Tue, 26 Aug 2014 13:34:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 26 Aug 2014 13:33:50 -0700 (PDT)
In-Reply-To: <>
References: <BAY169-DS62B5941BF0A9024964BB0AEEE0@phx.gbl> <> <BAY169-DS45F1C5036AB09CA44D0BC7AEDF0@phx.gbl> <> <>
From: Tom Ritter <>
Date: Tue, 26 Aug 2014 15:33:50 -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 20:34:12 -0000

On 26 August 2014 14:36, Chris Palmer <> wrote:
> On Mon, Aug 25, 2014 at 7:05 PM, Tom Ritter <> wrote:
>>>> No, PKP-RO is not meant to be cached. In this respect, it behaves similar
>>>> to Content-Security-Policy's reporting mechanism.
>>> Ah, interesting. I'm curious why not? Is there no use-case for allowing
>>> "report-only" pins to be persisted?
>> I think there definitely are, and I and most organizations I advise
>> would like that option.
> What would they get from it that they would not get from just
> consistently serving the PKP-RO header?

Well the whole threat model of HPKP (without preloading) is an
attacker that can MITM some TLS connections, but not all of them,
right?  Requiring PKP-RO to be on every load would allow an attacker
to strip the header on the connections they MITM. 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.