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

Chris Palmer <palmer@google.com> Fri, 19 October 2012 21:29 UTC

Return-Path: <palmer@google.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1738921F8748 for <websec@ietfa.amsl.com>; Fri, 19 Oct 2012 14:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kek7KqB8JTIy for <websec@ietfa.amsl.com>; Fri, 19 Oct 2012 14:29:16 -0700 (PDT)
Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F33F21F8721 for <websec@ietf.org>; Fri, 19 Oct 2012 14:29:15 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id b11so658511lam.31 for <websec@ietf.org>; Fri, 19 Oct 2012 14:29:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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; d=google.com; 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 10.152.106.110 with SMTP id gt14mr2186318lab.1.1350682154909; Fri, 19 Oct 2012 14:29:14 -0700 (PDT)
Received: by 10.112.39.226 with HTTP; Fri, 19 Oct 2012 14:29:14 -0700 (PDT)
In-Reply-To: <CA+cU71=t0u-rQWZE9jdmYEi53LN3kyrVZ_vnDH0DsJfdjnLrjA@mail.gmail.com>
References: <058.bddb3df732148e0ddb6c0b641bfbbd1f@trac.tools.ietf.org> <CAOuvq22smF0y5v-8Fju-BdCD2Qp5cBgX=izJQt0WOEH_T47qVg@mail.gmail.com> <2f70ca2ca41763af074a4abbe7bddd18.squirrel@webmail.dreamhost.com> <CA+cU71=t0u-rQWZE9jdmYEi53LN3kyrVZ_vnDH0DsJfdjnLrjA@mail.gmail.com>
Date: Fri, 19 Oct 2012 14:29:14 -0700
Message-ID: <CAOuvq22a6CSyGXR-LjFffp-AtN9WfobfgrHivqU_MZSwCD3qTA@mail.gmail.com>
From: Chris Palmer <palmer@google.com>
To: Tom Ritter <tom@ritter.vg>
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQn2BjvBa2MJqCmGLve03ZRXwPZRQEi3fTwjOPuHqeLASixycxO82GazbHk5t1hdzwl1Et3Nvg+9T8nsOM5AEt2hVtE+/WAYOcFJ/KtmBmrpCg6PHb3o5ncPLWlvV0OMXIj+u7MTY24JFOvnTOzB1GUecq/TbhDxB8wiCFjhLDGN4c3qR6pMyd+Ttz6HdLZanWw4ycpL
Cc: websec@ietf.org, sleevi@google.com
Subject: Re: [websec] #54: Specify a report-only mode
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Oct 2012 21:29:17 -0000

On Fri, Oct 19, 2012 at 8:56 AM, Tom Ritter <tom@ritter.vg> 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.

OK.

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

Agreed.

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

Agreed.

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