Re: [websec] #54: Specify a report-only mode

"Ryan Sleevi" <> Fri, 19 October 2012 16:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 07C8A21F85E7 for <>; Fri, 19 Oct 2012 09:10:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RfjBH2iLnRu0 for <>; Fri, 19 Oct 2012 09:10:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0EFCE21F859E for <>; Fri, 19 Oct 2012 09:10:22 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id B971C678063; Fri, 19 Oct 2012 09:10:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s=; bh=01fbTPN4wtUKf4SL3ggvgT750Wo=; b=UjF8McOYYxT2CdOrk cxy2AfaUtv+c4anPCZxCe+cw3lrkoLtSfsFM3uRQtASf7o96iBSnjcdyfFpNgrei FpaPNBPJtsOR2+QvWENGjbyOr9q+2XQuuMlzZEnq4YkrCbZMsXdjIylRiqcHTOgr 4csu+yR/9jfhWYQhx7AvCgmv4I=
Received: from ( []) (Authenticated sender: by (Postfix) with ESMTPA id 21FA9678055; Fri, 19 Oct 2012 09:10:21 -0700 (PDT)
Received: from (proxying for (SquirrelMail authenticated user by with HTTP; Fri, 19 Oct 2012 09:10:21 -0700
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 19 Oct 2012 09:10:21 -0700
From: Ryan Sleevi <>
To: Tom Ritter <>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [websec] #54: Specify a report-only mode
X-Mailman-Version: 2.1.12
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: Fri, 19 Oct 2012 16:10:23 -0000

On Fri, October 19, 2012 8:56 am, Tom Ritter wrote:
> >   - Should the report URI be allowed to specify HTTPS?
>  Yes.  This is potentially sensitive information, and we would like it
>  to be protected in transit.
> >   - If the report URI specifies HTTPS, and the report URI origin is the
> > same as the target URI, but the report URI violates either the PKP or
> > PKP-Report-Only policy, should the report still be submitted?
>  Honestly I don't see why not.  If it is an attacker, the attacker will
>  know the user rejected the TLS connection, and will have a good idea
>  it was because of pinning.  So what's the harm in telling them the
>  additional information.  Vs if it is a legit screw-up by the site,
>  they would still like to have the information.

I should have mentioned the other scenario that is closely related, which
is that independent of whether the report URI is different than the target
URI, what to do when the report URI violates its own PKP/PKP-Report-Only

The concern I have here is the disconnect between expectations. If the
site operator specifies HTTPS for a Report URI, presumably, they expect
exactly what you mentioned - that sensitive information will be protected
in transit.

If Report URIs fail the (previously stored) PKP policy, should the report
still be submitted or not? Does it match site author expectation?

A related, but subtle, implementation issue that is expected to arise if
HTTPS is allowed is ensuring that reporting loops are not formed. For
example, if submitting a report over HTTPS (via POST, presumably), and the
response data includes a PKP which the current connection violates, and a
report URI for the same URI as what was just posted, should the new
violation be reported? This can occur when the Report URI is independent
of the initial Target URI (so the second report would be unique) and when
the Report URI is identical to the Target URI (so the second report is

My reaction to all of this is that, when the PKP header is received
following the submission of a report, that the PKP header is ignored.

This is just some of the complexity with report URIs that will need to be
worked out - although I agree with your responses, and I agree that, even
for the complexity brought, it seems like it will be a necessary and
useful part of policy configuration.