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

Chris Palmer <> Fri, 19 October 2012 21:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1738921F8748 for <>; Fri, 19 Oct 2012 14:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Kek7KqB8JTIy for <>; Fri, 19 Oct 2012 14:29:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2F33F21F8721 for <>; Fri, 19 Oct 2012 14:29:15 -0700 (PDT)
Received: by with SMTP id b11so658511lam.31 for <>; Fri, 19 Oct 2012 14:29:15 -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:x-system-of-record; bh=JG2esl4CCtY/x5yVI01zKd2O+B2UdHD//TvOiVPUe5g=; b=MX1ulpQFVfPobV7E7R/Lf907nVQhgPgcAdrrs/T6Wo1/g7lvaC/635ynKDCl3obN/0 3HWEb7KNoie5ziUxZmFSdxPSEA/sgnN/8dNNMfsy7J1gKO5W9fL3/ek4QyxmHldbGji5 ZWUH8inGKcP7RcUNaIwxk+N49aYw1+dSg4CDWVHywx/W/35B47/BuUi80eSkZxk6eHmv S+avDubyuq/7HxW9/YkTMrrZmbEHXUn+3dYjWeDPSa5w5ChI1CaJXpW56OlyszYE6jGc z+gyLMUR+IMSP3dLHui+a3vI7fmffJMZNC+jLJ6gYWANoUlbfHMdm3oiq5doY6y8hOeV uj3g==
X-Google-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:x-system-of-record:x-gm-message-state; bh=JG2esl4CCtY/x5yVI01zKd2O+B2UdHD//TvOiVPUe5g=; b=THW6kiQAmVnjQVTeFNM+r2tnCp6wLlOoyAtrsGnINd8kYYspfEFUcjdBKfEb/IM9V2 MnaGcrkwc62JpgEZLAZVZZEYSAZNCFqyqmCs7thwe3H7akkPcv59F0bluDADxXp0wieS dA7RfRHk8a+4JYO2eyX/gFx2MOvoC0euDwjgCZo8z+nt7qlJ+UMpS6FtVIHNsBbp/yyD ME2TIXK0dTeTwgQBlmdUPQUNlBgZUAQ5oXDlcDw6AeH1pgBFGjqavPQL++9KTtg99P2K T7u9IHR37QK1Nuij8jioGnB7BenVDvqo/GnBgFrA7nbc/B8af7i0tgKtJ974m2KxcltO TjHQ==
MIME-Version: 1.0
Received: by with SMTP id gt14mr2186318lab.1.1350682154909; Fri, 19 Oct 2012 14:29:14 -0700 (PDT)
Received: by with HTTP; Fri, 19 Oct 2012 14:29:14 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 19 Oct 2012 14:29:14 -0700
Message-ID: <>
From: Chris Palmer <>
To: Tom Ritter <>
Content-Type: text/plain; charset="UTF-8"
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQn2BjvBa2MJqCmGLve03ZRXwPZRQEi3fTwjOPuHqeLASixycxO82GazbHk5t1hdzwl1Et3Nvg+9T8nsOM5AEt2hVtE+/WAYOcFJ/KtmBmrpCg6PHb3o5ncPLWlvV0OMXIj+u7MTY24JFOvnTOzB1GUecq/TbhDxB8wiCFjhLDGN4c3qR6pMyd+Ttz6HdLZanWw4ycpL
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 21:29:17 -0000

On Fri, Oct 19, 2012 at 8:56 AM, Tom Ritter <> wrote:

> It hurts me to say so, because it's going to be more work and
> complication and delay - but I agree a reporting system should be
> added.


>>>  {
>>>    "pin-validation-succeeded": (true|false),
>>>    "expected-pins": [ "sha1/blahblah", "sha256/foobar", ... ],
>>>    "validated-chain": [ "PEM blob of EE", "PEM blob of intermediate",
>>>  ..., "PEM blob of anchor" ]
>>>  }
> I like this, although I would include the entire PKP header, the Host
> header, and request URI.


>>   - Should the origin of the report URI be constrained the the origin of
>> the target URI?
> No, you should be allowed to specify a third party domain.  I could
> easily see a third party service collecting these reports as a free or
> paid service.  Google Webmaster Tools may even grow into collecting it
> and CSP violations.

I think we should follow precedent, i.e. CSP, and allow aribtrary
report URIs. This too hurts me to say. :) But consistency with
existing specifications and implementations is preferable to inventing
a new behavior for a similar feature.

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


>>     - Is there a blacklist or whitelist of headers that should be used to
>> prevent against abuse or compromise. For example, presumably including
>> cookies in the report submission for an invalid PKP over the same
>> connection that generated the invalid PKP would be bad, as it may
>> (will) lead to the compromise of the users' data.
> I don't think any headers other than the PKP, Host, and URL would be needed.

So, whitelist. That is good.

>>   - If the report contains validated certificates, what should the format
>> be? draft-josepfsson-pkix-textual [3] may be of normative use here.
> I have no opinion.

draft-josepfsson-pkix-textual works fine for me.