CT-Policy (was: Comments on draft-stark-expect-ct-00)

=JeffH <Jeff.Hodges@KingsMountain.com> Fri, 25 November 2016 02:53 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 E755412A20A for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 24 Nov 2016 18:53:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.398
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwLieLCXY__Y for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 24 Nov 2016 18:53:52 -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 2A643129688 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 24 Nov 2016 18:53:52 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cA6ag-0000Eb-EF for ietf-http-wg-dist@listhub.w3.org; Fri, 25 Nov 2016 02:50:18 +0000
Resent-Date: Fri, 25 Nov 2016 02:50:18 +0000
Resent-Message-Id: <E1cA6ag-0000Eb-EF@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 <Jeff.Hodges@kingsmountain.com>) id 1cA6aY-0000DK-Qd for ietf-http-wg@listhub.w3.org; Fri, 25 Nov 2016 02:50:10 +0000
Received: from gproxy4-pub.mail.unifiedlayer.com ([69.89.23.142]) by mimas.w3.org with smtp (Exim 4.84_2) (envelope-from <Jeff.Hodges@kingsmountain.com>) id 1cA6aS-0003BJ-3o for ietf-http-wg@w3.org; Fri, 25 Nov 2016 02:50:05 +0000
Received: (qmail 21617 invoked by uid 0); 25 Nov 2016 02:49:38 -0000
Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy4.mail.unifiedlayer.com with SMTP; 25 Nov 2016 02:49:38 -0000
Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id C2pb1u00K2UhLwi012pe6Y; Thu, 24 Nov 2016 19:49:38 -0700
X-Authority-Analysis: v=2.1 cv=K/+xQUmI 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=pGLkceISAAAA:8 a=ieNpE_y6AAAA:8 a=B6KMzFptAAAA:20 a=1XWaLZrsAAAA:8 a=48vgC7mUAAAA:8 a=cm27Pg_UAAAA:8 a=6nB-SSYuMVSMTV3WNkYA:9 a=pOPDreYXmCOAiQTG:21 a=M2CgWDUqhzQKZ-X-:21 a=QEXdDO2ut3YA:10 a=6kGIvZw6iX1k4Y-7sg4_:22 a=lOZzU2MLX5qQKtuoMSD9:22 a=nJcEw6yWrPvoIXZ49MH8:22 a=w1C3t2QeGrPiZgrLijVG:22 a=xmb-EsYY8bH0VWELuYED:22
Received: from c-73-202-80-238.hsd1.ca.comcast.net ([73.202.80.238]:52716 helo=[192.168.11.53]) 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 1cA6Zz-00059E-JG for ietf-http-wg@w3.org; Thu, 24 Nov 2016 19:49:35 -0700
To: IETF HTTP WG <ietf-http-wg@w3.org>
From: =JeffH <Jeff.Hodges@KingsMountain.com>
Message-ID: <500c4a29-2d72-70dc-681f-a713e6c1ab52@KingsMountain.com>
Date: Thu, 24 Nov 2016 18:49:34 -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-Source-IP: 73.202.80.238
X-Exim-ID: 1cA6Zz-00059E-JG
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: c-73-202-80-238.hsd1.ca.comcast.net ([192.168.11.53]) [73.202.80.238]:52716
X-Source-Auth: jeff.hodges+kingsmountain.com
X-Email-Count: 3
X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ==
Received-SPF: pass client-ip=69.89.23.142; envelope-from=Jeff.Hodges@kingsmountain.com; helo=gproxy4-pub.mail.unifiedlayer.com
X-W3C-Hub-Spam-Status: No, score=-3.9
X-W3C-Hub-Spam-Report: 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 1cA6aS-0003BJ-3o 3a34effe765ead8b6f74d1b69ec0c7f3
X-Original-To: ietf-http-wg@w3.org
Subject: CT-Policy (was: Comments on draft-stark-expect-ct-00)
Archived-At: <http://www.w3.org/mid/500c4a29-2d72-70dc-681f-a713e6c1ab52@KingsMountain.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33013
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>

coalescing replies to the three prior msgs in this thread...

On Wednesday, November 23, 2016 at 7:42 PM Martin Thomson 
<martin.thomson@gmail.com> wrote:
 >
 >> On 24 November 2016 at 13:33, =JeffH
 >> <Jeff.Hodges@kingsmountain.com> wrote:
 >> Emily had written:
 >>> Do you think it would be reasonable to reference the Chromium +
 >>> Mozilla CT policies but not define a particular policy in a normative
 >>> way?
 >>
 >> yep :)
 >
 > If HSTS is our benchmark, and that benchmark is so nebulous then it's
 > a bad one.

HSTS is actually not "nebulous" about this, I did not intend to imply that.

HSTS does define a "particular normative policy", though the HSTS spec 
was not required to prescribe the underlying details beyond what's below 
at [1] -- specifically section 8.4 where the one single normative 
(policy-enforcement-wise) "MUST" resides.


 > The objection that ekr raised was fair

Agreed.

Note that I had originally suggested including such context in the HTTP 
Expect-CT I-D:
 > [...]
 > A first draft of the Mozilla CT Policy is here:
 > 
<https://docs.google.com/document/d/1rnqYYwscAx8WhS-MCdTiNzYQus9e37HuVyafQvEeNro>
 > [...]
 >
 > The I-D should reference them in some fashion. The Moz draft has CT
 > and CT background info that may be useful to borrow for the I-D or
 > explicitly reference.
 >
 > Hm, it seems the term "CT qualified" ... -- as in a "CT qualified
 > certificate" -- has traction with both GOOG and Moz, perhaps it
 > ought to be employed as appropriate in the I-D.


On Thursday, November 24, 2016 at 4:55 PM Martin Thomson 
<martin.thomson@gmail.com> wrote:
 >> On 25 November 2016 at 02:52, Emily Stark <estark@google.com> wrote:
 >> But I do think it would be reasonable to advise site operators of
 >> the shape that a CT policy generally takes and what the moving
 >> parts are in practice (which is maybe what your point below is
 >> getting at).
 >
 > Yes.  This.

Agreed.


 > Ideally it would also describe the maximal policy, so an operator
 > could know where the bar is.  But that's impossible without
 > enumerating the set of possible log operators and I don't think we
 > want that.

Agreed, have the browsers vendors' CT-Policy specs address such details [2].

=JeffH


[1] https://tools.ietf.org/html/rfc6797#section-2.2

2.2.  HTTP Strict Transport Security Policy Effects

    The effects of the HSTS Policy, as applied by a conformant UA in
    interactions with a web resource host wielding such policy (known as
    an HSTS Host), are summarized as follows:

    1.  UAs transform insecure URI references to an HSTS Host into secure
        URI references before dereferencing them.

    2.  The UA terminates any secure transport connection attempts upon
        any and all secure transport errors or warnings.


  https://tools.ietf.org/html/rfc6797#section-5.2

  5.2.  HSTS Policy

    An HSTS Policy directs UAs to communicate with a Known HSTS Host only
    over secure transport and specifies policy retention time duration.

    HSTS Policy explicitly overrides the UA processing of URI references,
    user input (e.g., via the "location bar"), or other information that,
    in the absence of HSTS Policy, might otherwise cause UAs to
    communicate insecurely with the Known HSTS Host.

    An HSTS Policy may contain an optional directive -- includeSubDomains
    -- specifying that this HSTS Policy also applies to any hosts whose
    domain names are subdomains of the Known HSTS Host's domain name.


  https://tools.ietf.org/html/rfc6797#section-8.4

  8.4.  Errors in Secure Transport Establishment

    When connecting to a Known HSTS Host, the UA MUST terminate the
    connection (see also Section 12 ("User Agent Implementation Advice"))
    if there are any errors, whether "warning" or "fatal" or any other
    error level, with the underlying secure transport.  For example, this
    includes any errors found in certificate validity checking that UAs
    employ, such as via Certificate Revocation Lists (CRLs) [RFC5280], or
    via the Online Certificate Status Protocol (OCSP) [RFC2560], as well
    as via TLS server identity checking [RFC6125].



[2] Google and Mozilla are discussing "certificate transparency policy" 
here: <https://groups.google.com/a/chromium.org/forum/#!forum/ct-policy>
(aka  <ct-policy@chromium.org>)