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

Tom Ritter <tom@ritter.vg> Sun, 13 November 2016 14:54 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 0B85A129654 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 13 Nov 2016 06:54:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.498
X-Spam-Level:
X-Spam-Status: No, score=-8.498 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, 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 (1024-bit key) header.d=ritter.vg
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 e2eKl55m9ZmY for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 13 Nov 2016 06:54:19 -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 2A00412963D for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 13 Nov 2016 06:54:18 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c5w77-00027y-Km for ietf-http-wg-dist@listhub.w3.org; Sun, 13 Nov 2016 14:50:33 +0000
Resent-Date: Sun, 13 Nov 2016 14:50:33 +0000
Resent-Message-Id: <E1c5w77-00027y-Km@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 <tom@ritter.vg>) id 1c5w72-00025l-JX for ietf-http-wg@listhub.w3.org; Sun, 13 Nov 2016 14:50:28 +0000
Received: from mail-ua0-f182.google.com ([209.85.217.182]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <tom@ritter.vg>) id 1c5w6v-0005mF-Mk for ietf-http-wg@w3.org; Sun, 13 Nov 2016 14:50:23 +0000
Received: by mail-ua0-f182.google.com with SMTP id 20so46394522uak.0 for <ietf-http-wg@w3.org>; Sun, 13 Nov 2016 06:50:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v9B3WlXC8xjAEo5LnVPS3v3+AkUixPJJ+Fr46DsyF9Y=; b=f4Og1Uylflf01xXryrNfLnhAfZMWEBWgDVV5UnGN241csvAjgukAXViqPZPTpXAHAy xy8zsWm1jNnUEOLx581SiLgxMlzytE5wDfYrISLr4k0J38zmd/sQKay+qoBOxyoCQEKC AqT7shw/dlaYPonOtkEZSjtaWxT4BTMZFmjX8=
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=v9B3WlXC8xjAEo5LnVPS3v3+AkUixPJJ+Fr46DsyF9Y=; b=Efj0NRsVvx1QWxPcCCvBHY+sRkhpE/vc3huXenEo52O+lsrlSGVCKyZ/BbEoAjnP9w Oe2uxfEA/103Vc0NmnhZ6PrbCxvHG01Iuwl8hVmO3aVlYn2U+qlaMcxLqLWMryye6GkF gFKcUuBcgVIzm0WNZ+QEwAkxnqLQeqRxubkAITbzD/XuDytCnu285IakQ0ADkN+Q9A7Y CVrdPFQOmMngk9UbdFvErtNpQXPtOsGGRmWW6OKDC6VZg2oFkM75Tfc0n1b7WJky/8RD oFsm56/voN9Hv0lfIoSUo4LCBJpsqU2FeBB6/HBwj7hLTdqvlXD3UTQZOk0nnJmbg4ro 7GQQ==
X-Gm-Message-State: ABUngveE69S6AgL+ht9VwEK+Ou2l9V+y/3bB8xdWg06h4ScVi1Y57zqzwM8s3ksZABBlH9T3rsheQJKEJRX60WO4
X-Received: by 10.176.7.73 with SMTP id h67mr7370863uah.116.1479048594737; Sun, 13 Nov 2016 06:49:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.76.205 with HTTP; Sun, 13 Nov 2016 06:49:34 -0800 (PST)
In-Reply-To: <CAPP_2SbEM+_Ynf_Jcf4fUwp142rZ+69nF=dH6G0Tt_izYJC6xA@mail.gmail.com>
References: <CAPP_2SbEM+_Ynf_Jcf4fUwp142rZ+69nF=dH6G0Tt_izYJC6xA@mail.gmail.com>
From: Tom Ritter <tom@ritter.vg>
Date: Sun, 13 Nov 2016 08:49:34 -0600
Message-ID: <CA+cU71nd3zxqZgbdJYQ9EjLknbOqb7K0AHyP_XsuZF9gXVRORA@mail.gmail.com>
To: Emily Stark <estark@google.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=209.85.217.182; envelope-from=tom@ritter.vg; helo=mail-ua0-f182.google.com
X-W3C-Hub-Spam-Status: No, score=-5.2
X-W3C-Hub-Spam-Report: AWL=-0.217, 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, SPF_PASS=-0.001, W3C_AA=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1c5w6v-0005mF-Mk a800b64ef9aec82e893da18e3484e4d6
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Comments on draft-stark-expect-ct-00
Archived-At: <http://www.w3.org/mid/CA+cU71nd3zxqZgbdJYQ9EjLknbOqb7K0AHyP_XsuZF9gXVRORA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32879
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 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

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.

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.



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

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

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

-tom