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

Chris Palmer <> Tue, 26 August 2014 20:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E7B201A887A for <>; Tue, 26 Aug 2014 13:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.047
X-Spam-Status: No, score=-2.047 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, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SYWeysIZRgoU for <>; Tue, 26 Aug 2014 13:51:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E3511A883E for <>; Tue, 26 Aug 2014 13:51:24 -0700 (PDT)
Received: by with SMTP id i50so15205325qgf.6 for <>; Tue, 26 Aug 2014 13:51:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tQFde+fabl+F4ki6PdcGWWgQdht0SRn/SrJewJnmjC8=; b=XHFvdjKAF1eHPLJrbmTCofNOcWHTFGO1RCAXnigm5dvzIVZ07CnwZap3EXz39Y5QEU 3ciq0pB3blhQ1PUgdnnTriE+UhYBLbsI+Yub7DxRaa4QbZipyAiXqB8scDMas/zVEUaP DVQWcLbTFIdkWOUdaWaPAUATjr/kBOpgEt3uXUnhJH0n33+jpYNzqxs8Zl4quP9ndecF g/6QilLxje86tkVbewMBXfsxOgQnZWpVZaQi6o7M3RMK5gk5Bg1x1EnzweW+7bEKr4c0 STYiOed3JlGTN765CDeGOLUVNylXn22AkkGcIFXCr9mx2k6CEPgY6bsgKp2ie1TQVEbH JZ9A==
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:cc:content-type; bh=tQFde+fabl+F4ki6PdcGWWgQdht0SRn/SrJewJnmjC8=; b=HIUKZGp7Kr4iK3bJ7GyqtTxOxOTqy1m7MwKA5jYd2uyau9zAbWdMz+CmDdn5eZCo6q a082MtpEsnd6scjGucNTlkwcNK9U8LhaCn60sH035vwcLdZdYAmBxvuo0278ne7d4+2S 6f9cjRzqWPOWVmBseExdThv25LOrFJkOQxG4Su90B6qNMhzmICyTVNjudZ9HfcxBsQv0 sTnh3K0U8WZck9bc4VtugoGbqXXT10raC7pJhevRbf/4EDHjQaxpVYJACt0/npVXAsM8 ZEwetQZ8aRLxgmyHBxkSX5SRerVniDjE+spgrJEWICLLFS5en+HLsDtyl90TUcu/WvVT oXcw==
X-Gm-Message-State: ALoCoQlceoff9+Q1sc8kQAeqiefY9bjx69ICY17xeFs0SEFm6qoYPzZl3lA1yfycnHj/SkF426va
MIME-Version: 1.0
X-Received: by with SMTP id l74mr47448469qga.24.1409086283387; Tue, 26 Aug 2014 13:51:23 -0700 (PDT)
Received: by with HTTP; Tue, 26 Aug 2014 13:51:23 -0700 (PDT)
In-Reply-To: <>
References: <BAY169-DS62B5941BF0A9024964BB0AEEE0@phx.gbl> <> <BAY169-DS45F1C5036AB09CA44D0BC7AEDF0@phx.gbl> <> <> <>
Date: Tue, 26 Aug 2014 13:51:23 -0700
Message-ID: <>
From: Chris Palmer <>
To: Tom Ritter <>
Content-Type: text/plain; charset="UTF-8"
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:51:26 -0000

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