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

"Eric Lawrence" <> Tue, 26 August 2014 20:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B8A5B1A87DF for <>; Tue, 26 Aug 2014 13:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.821
X-Spam-Status: No, score=0.821 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RqNRCHuhOaNm for <>; Tue, 26 Aug 2014 13:58:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 32FEE1A87E9 for <>; Tue, 26 Aug 2014 13:58:55 -0700 (PDT)
Received: from BAY169-DS45 ([]) by over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22712); Tue, 26 Aug 2014 13:58:54 -0700
X-TMN: [ZnhUthzGYad+LSjMgB96LkXH0ryqQmlC]
X-Originating-Email: []
Message-ID: <BAY169-DS45D73636AA204DEEABC876AEDC0@phx.gbl>
From: Eric Lawrence <>
To: Chris Palmer <>, Tom Ritter <>
References: <BAY169-DS62B5941BF0A9024964BB0AEEE0@phx.gbl><><BAY169-DS45F1C5036AB09CA44D0BC7AEDF0@phx.gbl><><><> <>
In-Reply-To: <>
Date: Tue, 26 Aug 2014 15:58:54 -0500
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="UTF-8"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
X-OriginalArrivalTime: 26 Aug 2014 20:58:54.0921 (UTC) FILETIME=[8C2BC390:01CFC170]
X-Mailman-Approved-At: Tue, 26 Aug 2014 14:07:37 -0700
Cc:, 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:59:00 -0000

> primarily a debugging aid for The Alice Foundation and BobCorp to get
> PKP working. ("What all Trents do we need to trust, anyway?")

As a site operator, I'd think of PKP-RO as a debugging aid more along the 
lines of: "If I turn this thing on, will anything break for anyone?"

If PKP-RO doesn't have the same semantics as PKP, its utility for answering 
that question declines.


-----Original Message----- 
From: Chris Palmer
Sent: Tuesday, August 26, 2014 3:51 PM
To: Tom Ritter
Cc: Eric Lawrence ; ; IETF 
WebSec WG ; Ryan Sleevi
Subject: Re: [websec] draft-ietf-websec-key-pinning

On Tue, Aug 26, 2014 at 1:33 PM, Tom Ritter <> wrote:

> Well the whole threat model of HPKP (without preloading) is an
> attacker that can MITM some TLS connections, but not all of them,
> right?

"""By effectively reducing the number of authorities who can
authenticate the domain during the lifetime of the pin, pinning may
reduce the incidence of man-in-the-middle attacks due to compromised
Certification Authorities."""

The threat model is that The Alice Foundation wants to trust only
Trents 1, 4, and 9, and no other Trents, to vouch for her identity.
That way, if Trent 6 mis-issues for The Alice Foundation, Mallory
cannot make use of the mis-issued certificate in an attack.

But, yes, Mallory can still attack CarolCorp, if CarolCorp does not
use pinning or pins to Trent 6.

> 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?")