[expect-ct] Is expect-ct policy intended for long-term use? (plus: no user recourse)

=JeffH <Jeff.Hodges@KingsMountain.com> Thu, 24 November 2016 00:52 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 891D91294A5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 23 Nov 2016 16:52:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Status: No, score=-8.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id bEWYi6vtwGLy for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 23 Nov 2016 16:52:00 -0800 (PST)
Received: from frink.w3.org (frink.w3.org []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222941293E0 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 23 Nov 2016 16:52:00 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c9iCg-0000ai-Md for ietf-http-wg-dist@listhub.w3.org; Thu, 24 Nov 2016 00:47:54 +0000
Resent-Date: Thu, 24 Nov 2016 00:47:54 +0000
Resent-Message-Id: <E1c9iCg-0000ai-Md@frink.w3.org>
Received: from mimas.w3.org ([]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <Jeff.Hodges@kingsmountain.com>) id 1c9iCZ-0000YT-BJ for ietf-http-wg@listhub.w3.org; Thu, 24 Nov 2016 00:47:47 +0000
Received: from gproxy9-pub.mail.unifiedlayer.com ([]) by mimas.w3.org with smtp (Exim 4.84_2) (envelope-from <Jeff.Hodges@kingsmountain.com>) id 1c9iCT-0002XR-5D for ietf-http-wg@w3.org; Thu, 24 Nov 2016 00:47:42 +0000
Received: (qmail 30371 invoked by uid 0); 24 Nov 2016 00:47:13 -0000
Received: from unknown (HELO cmgw2) ( by gproxy9.mail.unifiedlayer.com with SMTP; 24 Nov 2016 00:47:13 -0000
Received: from box514.bluehost.com ([]) by cmgw2 with id Bcn81u00B2UhLwi01cnBxz; Wed, 23 Nov 2016 17:47:11 -0700
X-Authority-Analysis: v=2.1 cv=YNIMl32x c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=L24OOQBejmoA:10 a=48vgC7mUAAAA:8 a=iGl6bVRPtGMVb8hWRC4A:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
Received: from [] (port=46052 helo=[]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1c9iBx-0003lk-Nf for ietf-http-wg@w3.org; Wed, 23 Nov 2016 17:47:09 -0700
To: IETF HTTP WG <ietf-http-wg@w3.org>
From: =JeffH <Jeff.Hodges@KingsMountain.com>
Message-ID: <8635e96f-44a0-1024-8cd2-43ed7100679e@KingsMountain.com>
Date: Wed, 23 Nov 2016 16:47:07 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box514.bluehost.com
X-AntiAbuse: Original Domain - w3.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - KingsMountain.com
X-BWhitelist: no
X-Exim-ID: 1c9iBx-0003lk-Nf
X-Source-Sender: ([]) []:46052
X-Source-Auth: jeff.hodges+kingsmountain.com
X-Email-Count: 4
X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ==
Received-SPF: pass client-ip=; envelope-from=Jeff.Hodges@kingsmountain.com; helo=gproxy9-pub.mail.unifiedlayer.com
X-W3C-Hub-Spam-Status: No, score=-3.3
X-W3C-Hub-Spam-Report: AWL=0.561, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1c9iCT-0002XR-5D 418fdb728e592ef9ef2d8d6e72f53ece
X-Original-To: ietf-http-wg@w3.org
Subject: [expect-ct] Is expect-ct policy intended for long-term use? (plus: no user recourse)
Archived-At: <http://www.w3.org/mid/8635e96f-44a0-1024-8cd2-43ed7100679e@KingsMountain.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32979
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>

WRT "Expect-CT" <https://tools.ietf.org/html/draft-stark-expect-ct> (aka 
"the I-D" in the below)...

Is the expect-ct policy intended to be used long-term by servers?

I.e., is this server-declared expect-ct policy only a stop-gap until all 
browsers natively enforce their vendors' "ct policies"?

At first glance, it seems the answer is "yes, expect-ct has long-term 
usefulness" given the language in
i.e., a host's declaration of expect-ct policy is stating that the UA
must terminate any connection to that host (and port?) that does not
satisfy the UA's ct policy.

However, given this..

On Sunday, November 13, 2016 at 4:47 AM, Emily Stark wrote:
 > That is, eventually, when browsers require CT for all certificates,
 > [...] I see Expect-CT as a way that individual sites
 > can opt in to the future early ("the future" being when browsers
 > require CT for all certificates)

..it sounds like the browsers intend to do that in any case, and if so, 
on what timescale?

I.e., is it worthwhile to go through all the work to formally define 
Expect-CT in an RFC?

Though, if there is some functionality that a server-declared expect-ct 
policy stipulates that is not intended to be implemented by default in 
near- to intermediate-term, then formally specifying Expect-CT perhaps 
has a reasonable cost-benefit regardless. Or also if explicit 
server-declared "expect-ct" policy would be useful to the long-tail of 
HTTPS clients other than the dominant browsers.

Perhaps one should consider having the expect-ct policy additionally 
mean that there is "no user recourse" to connection termination as a 
result of CT-policy violation. I note the I-D does not presently state 

See <https://tools.ietf.org/html/rfc6797#section-12.1> for how this is
discussed in HSTS. You might consider adding "no user recourse" to a "UA
implementation advice" section.

Though, like any of this (including HSTS), the browsers could in the 
future decide that they will have a "no user recourse" policy by default 
for all secure transport establishment failures. It's a question of how 
far in the future might that occur (in order to justify 
present-to-intermediate-term work).