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

Emily Stark <> Thu, 24 November 2016 15:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19EDB1297E8 for <>; Thu, 24 Nov 2016 07:57:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.497
X-Spam-Status: No, score=-8.497 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, HTML_MESSAGE=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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zuzqeBWyH-ka for <>; Thu, 24 Nov 2016 07:57:26 -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 62C7E129657 for <>; Thu, 24 Nov 2016 07:57:26 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c9wLH-0006kb-BY for; Thu, 24 Nov 2016 15:53:43 +0000
Resent-Date: Thu, 24 Nov 2016 15:53:43 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c9wLA-0006iT-EZ for; Thu, 24 Nov 2016 15:53:36 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1c9wL4-0008Rj-Dp for; Thu, 24 Nov 2016 15:53:31 +0000
Received: by with SMTP id a124so85196407ioe.2 for <>; Thu, 24 Nov 2016 07:53:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CjTFyPpqyFuf+RRW0wik/D0VA+cM692pjTXWdsp1ZgY=; b=jbZ+tCDc3liizhUZlg+JdfofXSqIZWEBZmz9JcaoepeTAPiFwwP2D9Bx2FtEyM5ANd 5meI37LpSYpqciMwrw+BUHIYfc+pg89e7OeOKGal+2OAwLss0GBvNksma56OK86fsPzJ b5ftaRwqKXN+kB9C0G7Obd0Utj2gdcdGrrjf31OMzw0ubuaKSWIQEMyI0gGrO9Pb1Y1p sR7oMo5ogtxlt1IcvLgyTP5ZJx2vBN7lFW6owGaHu8AU7nzn2p1ukvlmZW8wXlYewpug 2xjm1lT0Y6aW/WgcQlLyf9F/EUVFkr/79FTEg5zo6XuMElwooBFfVnoanjqxTj0YoYPd lGOA==
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=CjTFyPpqyFuf+RRW0wik/D0VA+cM692pjTXWdsp1ZgY=; b=W3pjGoO3r7OhwZp7o40yQFF0zYztY2JcYJl4PCJdS6JfHdQHEoEiSZOP2Mzdp6kohF Ya3sH9FjnL9SfDrjO3YTdP59GZb2pyYrNNUBJDsnNFfYbwh0Mlw52xtLzv2iaLF/7UZo SNODMJwS1hEvvo2NE6u6LjFn1hCQDSAalQHhtw/kbV8bEeMrlrrdL+E+WpLINt1E7ca7 peubGIIAzFxeE81GXRIVc5U6CwTmFpovnSOI1xlvt7ZBcK2TPFxar1Ln+onTaxfqh89D y4vuU5nRDETBiQXwjhjZ0lHbH2nZqqRyHpK2opCyeswVMMoBsgPoVfzQMDKy51Oi+Jtx u8QA==
X-Gm-Message-State: AKaTC01y62KoVdTNSEYwldRGyx6mfFPEiZQalTX3iyJ5vBzbw/eEYeExVywqqc8h0SK2iGpKMbX2guNwP351ul85
X-Received: by with SMTP id u2mr2631494itg.47.1480002784124; Thu, 24 Nov 2016 07:53:04 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 24 Nov 2016 07:52:43 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Emily Stark <>
Date: Thu, 24 Nov 2016 07:52:43 -0800
Message-ID: <>
To: Martin Thomson <>
Cc: =JeffH <>, IETF HTTP WG <>, Eric Rescorla <>
Content-Type: multipart/alternative; boundary="94eb2c0b017437654605420e00f4"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.0
X-W3C-Hub-Spam-Report: AWL=1.914, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1c9wL4-0008Rj-Dp d02539cefed8d70d276fcfc15709133d
Subject: Re: CT-Policy (was: Comments on draft-stark-expect-ct-00)
Archived-At: <>
X-Mailing-List: <> archive/latest/32995
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Wed, Nov 23, 2016 at 7:42 PM, Martin Thomson <>

> On 24 November 2016 at 13:33, =JeffH <>
> wrote:
> >> 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.  The objection that ekr raised was fair: how do I know what
> baseline I have to reach in order to avoid the footgun.
> Maybe there are weasel words that can be used to allow browsers to
> choose their own logs.  But can we at least write down the basics: the
> certificate is logged, the TLS handshake includes an SCT, etc...
> Surely the current set of policies indicates a common set of
> principles that can be written into a specification.

Are you imagining that this common set of principles is the minimum policy
that a UA should enforce for an Expect-CT host, or the literal policy?

If the former, then it doesn't really solve the problem: it doesn't give
you enough information to know what baseline you have to reach in order to
avoid the footgun. If the spec says that the TLS handshake must include an
SCT, but in practice all browsers require 2 SCTs with requirements on what
logs those SCTs come from, then we haven't really helped anyone out.

If the latter, then we end up in a weird place if a UA wants to enforce a
stricter policy for all certificates. Expect-CT hosts shouldn't be subject
to a looser policy (e.g. one SCT required) than the policy that the UA uses
more generally.

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

> If we're well outside 6962 territory and into policy land, at least
> proscribe what falls into policy.  Reading the Mozilla policy, it
> seems like number and choice of logs might be the only places where
> variation is possible.