Re: Comments on draft-stark-expect-ct-00

Emily Stark <estark@google.com> Mon, 14 November 2016 02:40 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCAD31294FC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 13 Nov 2016 18:40:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.998
X-Spam-Level:
X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXXLntu7lXRO for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 13 Nov 2016 18:40:42 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B276F129474 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 13 Nov 2016 18:40:42 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c678i-0008PN-OG for ietf-http-wg-dist@listhub.w3.org; Mon, 14 Nov 2016 02:36:56 +0000
Resent-Date: Mon, 14 Nov 2016 02:36:56 +0000
Resent-Message-Id: <E1c678i-0008PN-OG@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <estark@google.com>) id 1c678Y-0008OY-SA for ietf-http-wg@listhub.w3.org; Mon, 14 Nov 2016 02:36:46 +0000
Received: from mail-it0-f42.google.com ([209.85.214.42]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <estark@google.com>) id 1c678S-000628-MJ for ietf-http-wg@w3.org; Mon, 14 Nov 2016 02:36:41 +0000
Received: by mail-it0-f42.google.com with SMTP id b123so4475446itb.0 for <ietf-http-wg@w3.org>; Sun, 13 Nov 2016 18:36:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e3nvYuolf29WbdZsE0k4RsYdw38XFE4wK7TbVxNv4gY=; b=Q6H/X/211eWuTr4rPYj3hh8blSXX626ztsuoWbzLQEUIuSE1YCD3eNiiMMmHkqcnOd zW5OFK+mQiG8IWN2gBw7mNrfJ/dduQv40rvbiglRlEQFpEzW0lD33WpkAX+NaGWl49Nv 83b09hKLJwlQTG7kkRQROAhu2DsHkCcFCsfgMrfwxp1UkTp2qPP35O/DU4WOGHoCmbWH 3xNkupHYpneZ1lzo6GjMSFNo71FI3VGXEUAbNPd2Fq3SDsfP+mahD5wyGNC1Lk1U2NFJ 8okrEUOJCx61p+4TxfmpK9SJoKS/xkvMciKtrrzI4a1DdkOcNVmkqNXIWZWj+V4Ni8be 3Jmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e3nvYuolf29WbdZsE0k4RsYdw38XFE4wK7TbVxNv4gY=; b=mjTzDKi16I2kK+PtVL6WtReXL9v44iqMVV2HBN6Qkg2ouz/A86huBvouOWHBlDIi4W u5P1vrL3AH068aIw6ZH/N8gIXzkUl8gedMnElEN81c4uyrJAEnafMEcLQ0tWsZTlkxRO PSLnzyl3uxJ/ilZBq+0+rkAKR6bAgzOTq7FEmVH41gEwKoJ5bTIjoowdzpA6dryT3VSN CkMhUcmS/NN568cyj68WeJF8MO61XhJA3uUcRGWwsoptNKTDGrTiq9Kjdit9fjcH/07g x+y0rU1tUMzerBpUo0uWySxvF7555JyzRghQcBD9hbM5RgEFLEPIw7xF35d0dV9YL72L 4lhQ==
X-Gm-Message-State: ABUngve1AZNIxOTazqBlZCLxqOQb8pgaLcjYncxZ3LRJJF7yej7Xznm+qyFRq/lrbT6fZ57/i4ygUAcza2LyUWm5
X-Received: by 10.107.5.210 with SMTP id 201mr21547748iof.189.1479090974151; Sun, 13 Nov 2016 18:36:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.136.84 with HTTP; Sun, 13 Nov 2016 18:35:53 -0800 (PST)
In-Reply-To: <CA+cU71nd3zxqZgbdJYQ9EjLknbOqb7K0AHyP_XsuZF9gXVRORA@mail.gmail.com>
References: <CAPP_2SbEM+_Ynf_Jcf4fUwp142rZ+69nF=dH6G0Tt_izYJC6xA@mail.gmail.com> <CA+cU71nd3zxqZgbdJYQ9EjLknbOqb7K0AHyP_XsuZF9gXVRORA@mail.gmail.com>
From: Emily Stark <estark@google.com>
Date: Mon, 14 Nov 2016 11:35:53 +0900
Message-ID: <CAPP_2SYLsu1d2y8jxZDN=549=M4Z8ib4t7K92rdOJDYoxft8AQ@mail.gmail.com>
To: Tom Ritter <tom@ritter.vg>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=209.85.214.42; envelope-from=estark@google.com; helo=mail-it0-f42.google.com
X-W3C-Hub-Spam-Status: No, score=-6.3
X-W3C-Hub-Spam-Report: AWL=1.091, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1c678S-000628-MJ 61b2474295beb51065ac95ecf5b4f3d1
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Comments on draft-stark-expect-ct-00
Archived-At: <http://www.w3.org/mid/CAPP_2SYLsu1d2y8jxZDN=549=M4Z8ib4t7K92rdOJDYoxft8AQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32881
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Sun, Nov 13, 2016 at 11:49 PM, Tom Ritter <tom@ritter.vg> wrote:
> On 13 November 2016 at 06:47, Emily Stark <estark@google.com> wrote:
>>> What's the rationale for not caching the directive in report-only mode.
>>> If the purpose of the report-only mode is to tell you when you have
>>> nonconforming servers, then don't you want to be able to turn it on
>>> on server A and detect hwen server B is broken? That seems like it
>>> doesn't work if you don't cache.
>>
>> I'm tempted to say "because that's how HPKP does it", but that's
>> probably not the answer you're looking for. :) I'd expect that sites
>> would generally serve the report-only header on all responses
>> unconditionally. I can't really think of a common misconfiguration
>> scenario that would cause a CT violation and would *also* cause the
>> header to not be served, but maybe that's a failure of imagination on
>> my part.
>
>
> The behavior of HPKP-RO was considered widely (by everyone except the
> authors) to be a mistake. The draft was past Last Call though, and
> everyone was exasperated at that point so it was not corrected despite
> there generally being consensus otherwise. This thread will give you a
> good idea of that discussion:
> https://www.ietf.org/mail-archive/web/websec/current/threads.html#02173

Thanks for the link. That's helpful context. I took an initial look
through it (need to do a second more careful reading) and so far the
argument that I personally find most convincing is the principle of
least astonishment argument.

>
> Report Only mode should behave the same as Enforcement Mode in all
> regards except enforcement. That's the only way site admins will feel
> confident that they have a good handle on their configuration not
> breaking things.

Note that report-only mode probably has to behave differently than
enforcement mode in at least one way, which is how the headers are
processed when received on a non-CT-compliant connection. An
enforcement header, if received on a connection that is not
CT-compliant, will be ignored, but a RO header should at least cause a
report to be sent. In a world where we cache RO headers, should a RO
header be cached if received on a non-CT-compliant connection?

>
> The most immediate examples of this causing issues is in load-balanced
> deployments (such as multicast or IP/TCP-level load balancing) where
> Server A is correctly configured but Server B is not.

While I can imagine misconfigurations where Server A is serving
CT-compliant connections and Server B is not, I have some trouble
imagining misconfigurations where Server A is making CT-compliant
connections and Server B is not *and* Server A is serving the header
and Server B is not.

To make this concrete, here are the types of misconfigurations I have
in mind that reporting would help with:
1. A CA or site operator misunderstands a UA's CT policy, or has a bug
in conforming to it, and issues/serves a certificate that violates it.
2. A site operator wants to measure the impact of client clock skew
before turning on enforcement mode. (This is a bit of an edge case, as
I suspect it's not very common that a client clock is wrong in such a
way that the certificate validates but the SCT does not.)
3. A site is serving SCTs via stapled OCSP response or TLS extension
and learn about bugs in their implementation and/or the reliability of
their OCSP responder.

In those situations, there's no reason to think that the violating
connection would not be properly serving the report-only header. And
in situations where the site is not properly serving the report-only
header consistently, caching RO won't help debug that unless the
failure to serve the header correlates with a failure to serve a
CT-compliant connection.

>
>
>
> More comments:
>
> Going with an 'enforce' directive as opposed to a second header
> prevents sites from deploying a more conservative enforcing mode and a
> more aggressive testing mode. This doesn't seem to be an issue because
> there are no knobs except max-age to turn. (Yet?)

That was the thinking behind that, yes.

>
> There is no includeSubdomains directive (which would also make
> persistent of Report-Only very important.) I'm not saying this is bad,
> but HSTS and HPKP have the feature. On the other hand - it would
> probably necessitate the availability of the two modes...

Yes. In discussion with other browsers, our priority has been to do
something as simple as possible while still being useful, and we
thought that there might not be high-demand for includeSubDomains. I'd
be interested to hear from site operators whether that's true or not.
As you pointed out, no includeSubDomains also means that there's no
need for two separate headers (and thus no need to define how they
interact with each other, etc.).

>
> Like HSTS and HPKP, Expect-CT can be used as a (low-bandwidth)
> tracking mechanism, so that should go into Privacy Considerations.

Definitely will do. The emptiness of Privacy Considerations at the
moment shouldn't be taken to mean that there are none, just that I
haven't gotten to that section yet. :)

>
> -tom