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

Tom Ritter <> Sun, 13 November 2016 14:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B85A129654 for <>; Sun, 13 Nov 2016 06:54:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.498
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e2eKl55m9ZmY for <>; Sun, 13 Nov 2016 06:54:19 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A00412963D for <>; Sun, 13 Nov 2016 06:54:18 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c5w77-00027y-Km for; Sun, 13 Nov 2016 14:50:33 +0000
Resent-Date: Sun, 13 Nov 2016 14:50:33 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c5w72-00025l-JX for; Sun, 13 Nov 2016 14:50:28 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1c5w6v-0005mF-Mk for; Sun, 13 Nov 2016 14:50:23 +0000
Received: by with SMTP id 20so46394522uak.0 for <>; Sun, 13 Nov 2016 06:50:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id h67mr7370863uah.116.1479048594737; Sun, 13 Nov 2016 06:49:54 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 13 Nov 2016 06:49:34 -0800 (PST)
In-Reply-To: <>
References: <>
From: Tom Ritter <>
Date: Sun, 13 Nov 2016 08:49:34 -0600
Message-ID: <>
To: Emily Stark <>
Cc: HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
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: 1c5w6v-0005mF-Mk a800b64ef9aec82e893da18e3484e4d6
Subject: Re: Comments on draft-stark-expect-ct-00
Archived-At: <>
X-Mailing-List: <> archive/latest/32879
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 13 November 2016 at 06:47, Emily Stark <> 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:

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.