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

Ryan Sleevi <> Thu, 04 September 2014 23:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ABD4F1A0267 for <>; Thu, 4 Sep 2014 16:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Status: No, score=-2.046 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gl_tme2pjr6v for <>; Thu, 4 Sep 2014 16:09:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 514A71A023E for <>; Thu, 4 Sep 2014 16:09:07 -0700 (PDT)
Received: by with SMTP id hq11so11568964vcb.14 for <>; Thu, 04 Sep 2014 16:09:06 -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=H5ofHEGipBhPp9r/7KxUdoQSqeQNXuOtXFsmvwvtFRk=; b=N0o1riEXqHIDfQkflenAznM449H55sz78uxYR16gHiBoxMyBhQD4Ta4Wy3o9h2tkt4 qUFstwYFknmgrTkOj/RfG75iyymeSuAuKeBr6X8Mycb71AT6RAtYe+6K/A4fhg9ozxiW Y+fow5Q7ddbYRMbBWqNwTMPiBtjr5AJo55S5PwCu3SxmuzdNUAznkDg2Rz+EPa9J6Svc kECspMmCi4NJuZFEcNnjHT3hH71OlbWRUXaowo5cymOiOsi368PzdnyeubzEtMQIJQo9 DJC1NEbi1vVcOuF67ledN5ydgCWT9lbnBlaWLdm/cmAXAwCrtU9j2G/+TRtNwzIQ5t+e PmwQ==
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=H5ofHEGipBhPp9r/7KxUdoQSqeQNXuOtXFsmvwvtFRk=; b=Cb5JUXjtReaDhqIIoyP5dft99sLEnBy74fcXAI9KNeBVGMZ7WuneA7WrOC0Av0f476 AWicnzzNSC6orpL2uGHqRQFzlITcUNNOe7yWYg4a84WeQK+yweE1NbhVmb5/MQvPIGx1 Ii+dvYma8fPZTl0QTPfWR1GI8RX+HByE+Lhy/u/5dj7Thkl/dvJKV4TePrhyfo0H0Vi7 l5VXbJuwW3CsjgV4UIGxP6w9qQ+vqh1HlZh3YPUZcjVMN5jMCzDxVSKxYTS1UEaNaBaa O2pmtKHpbib7UEo3OUrxgYmFCrighkXmodeM+/4VD2BPQIu05JsrOqxAHhF5vSioXBxl e3kg==
X-Gm-Message-State: ALoCoQmLuoM9Jjmi2v8L79UP/kCcwn4n9xO5wcmFKeK6zadig5/hiVVAHwW55rCf5QP8pry+RWkx
MIME-Version: 1.0
X-Received: by with SMTP id cn3mr5996229vdd.3.1409872146104; Thu, 04 Sep 2014 16:09:06 -0700 (PDT)
Received: by with HTTP; Thu, 4 Sep 2014 16:09:05 -0700 (PDT)
In-Reply-To: <>
References: <> <BAY169-DS311951F23960F4605A0CB0AEDA0@phx.gbl> <> <BAY169-DS421419C50B5700132829BBAEDA0@phx.gbl> <>
Date: Thu, 04 Sep 2014 16:09:05 -0700
Message-ID: <>
From: Ryan Sleevi <>
To: Trevor Perrin <>
Content-Type: multipart/alternative; boundary="001a1133ce6e72a47f05024570b5"
X-Mailman-Approved-At: Fri, 05 Sep 2014 02:20:28 -0700
Cc: draft-ietf-websec-key-pinning <>, 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: Thu, 04 Sep 2014 23:09:10 -0000

On Thu, Sep 4, 2014 at 4:02 PM, Trevor Perrin <> wrote:

> 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
> victim?

Yes, and that's a user visible effect, rather than transparent. It also
requires that a connection be validated first, whereas the very definition
of PKP-RO is that you send it when a connection is not validated.

> 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.

First, the attacker can only mount the hostile attack after having first
established a good connection. PKP-RO allows an attacker to perpetually
mount a hostile attack.
Second, the presence of a pinning error is an inherently rate-limiting
factor to the user experience. You're not going to be able to trigger 100
reports if you're causing the user 100 error pages.
Third, it seems like you're arguing for removing report-uri altogether,
given the privacy and DoS risks identified. That is, the more that  you
establish RO is similar to PKP in level of what an attacker can do, the
more it argues for removing report-URI entirely.