Re: Call for Adoption: Expect-CT

Emily Stark <> Sat, 10 December 2016 02:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98F76127A91 for <>; Fri, 9 Dec 2016 18:01:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.896
X-Spam-Status: No, score=-9.896 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=-2.896, 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 I50NLL_trl9d for <>; Fri, 9 Dec 2016 18:01:54 -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 43F49126D74 for <>; Fri, 9 Dec 2016 18:01:53 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cFWwE-0002Zm-Cl for; Sat, 10 Dec 2016 01:58:58 +0000
Resent-Date: Sat, 10 Dec 2016 01:58:58 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cFWw2-0002Yf-H9 for; Sat, 10 Dec 2016 01:58:46 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1cFWvv-0003YL-HV for; Sat, 10 Dec 2016 01:58:41 +0000
Received: by with SMTP id p42so91929402ioo.1 for <>; Fri, 09 Dec 2016 17:58:18 -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=186lQxKDEBBFRvhb0LKYYhBwtw0LtwAKROThBFWEhvo=; b=GC45zdox6U2J1FgKzoA/UL6hT6WoWajByRl4J5QJN2M/y5GRvbCjmF9V7m6cW2U3Zf Yw4+4Kk5dizpXgXkd4sq5Ka7H+IN2Y3DMzH5WOYGnhp7f4UR2FfD+Yj39lZbVnWKLXtK ohWftj3eqaJXLgic/JhVoiPpw2BW3trI31BbshzXbGSyzB+MarHdcirED5RsYJb6tmTL vRtKB/UUnOyG5kYBtBCnX4BPkM0EaHrgkXDEBjNuF4HeqVGRHFaDGiymcCHq3qcC1B5x QyBWipIFLUz94xbPUbtnWddGQGnR63xBpckjILOapd3xcpesocmk9p1GER36nMXvu8s/ Yf3Q==
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=186lQxKDEBBFRvhb0LKYYhBwtw0LtwAKROThBFWEhvo=; b=ODB2nTNoyn6dCJJD1zsnMCx1YWfWeQb3L5iJoZE5gH+AXVIRZ/FtNmQJMwIMm3ESMR 7q2wiLrm5TShjXUCeDN/PRqZRu6mVtJ9Gb+frkvZ6JCsBRjG/k4g1NLS8aKHMid70ggh rQZMxneqe8dL1vV8XhLjmDSAcI27RrttKgifcRfWFR/H+rjzLhKgiSCq/fmq9OqhdW7C 0oWmGcFIJqYLGkWai+WaPzBoV02FIdCjPY21ougfe9hBF8wuwArOhRYCzJl6N0Ztu5I4 38U4Q5dmoPeHspUOBQvRp90FBCrifD4q3qLhmZadrrG7sLsyG/TZySX/doc616KJty7A R8jw==
X-Gm-Message-State: AKaTC02dgeaqZ6NIIj1exfpZKS7FHAF6tGpKEvY02saibPpu5gSa3GKuhAnMiAZypurpA+G6fofHHnL0gr6CLakt
X-Received: by with SMTP id z194mr1190638itz.121.1481335092730; Fri, 09 Dec 2016 17:58:12 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 9 Dec 2016 17:57:51 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Emily Stark <>
Date: Fri, 09 Dec 2016 17:57:51 -0800
Message-ID: <>
To: "Roy T. Fielding" <>
Cc: Mark Nottingham <>, HTTP Working Group <>, Patrick McManus <>
Content-Type: multipart/alternative; boundary="001a113b0716ff37b0054344333c"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.9
X-W3C-Hub-Spam-Report: AWL=2.101, 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.996, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1cFWvv-0003YL-HV 95840239eeae2cdee8149b483b31e345
Subject: Re: Call for Adoption: Expect-CT
Archived-At: <>
X-Mailing-List: <> archive/latest/33150
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Fri, Dec 9, 2016 at 12:13 PM, Roy T. Fielding <> wrote:

> > On Dec 7, 2016, at 8:05 PM, Mark Nottingham <> wrote:
> >
> > Again, there seemed to be strong support in Seoul, and now on the list,
> for adopting this draft:
> >
> > <>
> >
> > Please comment / express support on list.
> I don't have a problem with someone at IETF working on a solution to the
> problem, but I have serious issues with this draft as it currently stands:
>  1) It effectively adds a binary TLS control option in the form of a
>     verbose HTTP response header field to be sent in ALL https responses.
>     That doesn't make any sense, on so many levels.
>     a) it's a layer violation (wrong code parses it);
>     b) it's incredibly inefficient to send the information every time
>        when it only needs to be received once;

This is a recurring problem common to HSTS, HPKP, Content-Security-Policy,
and probably others, and I'm hopeful that the solutions being discussed at will
help the situation.

>     c) it's processing is in the critical path of response handling
>        even though the information is only useful for "future connections"
>        (and ignored by all non-implementators);

It's also used on the current connection, to report violations. If a server
serves an Expect-CT header with a report-uri on a connection that is not
CT-compliant, then the UA sends a report to notify the server.

>     d) the same control might be desirable for non-HTTP uses of TLS.
>  2) The header field is poorly named (see Expect), doesn't limit itself to
>     responses (aside from having no definition for other contexts), and has
>     a field value syntax matching that of Set-Cookie (FFS).

These seems like eminently solvable problems.

I'll note that the field value syntax is chosen to align with HSTS and HPKP
so that browsers don't have to implement new parsers to support Expect-CT.

> Why is this not a TLS option, preferably signaled by an attribute of the
> certificate itself?  The other information could be supplied at a
> well-known
> location or by reference to a third-party reporting mechanism.
> What is the justification for sending this information in HTTP response
> header fields when it is independent of the current response and only
> useful for later connections?  As a general design rule, we use links
> for that.

See above; it's not only useful for later connections.

> I know HTTP is "comparatively easy" when it comes to adding all sorts
> of fun options, but does this extension justify its own cost?  Why can't
> it be accomplished via the certificate management mechanism, entirely
> outside the scope of this working group?

It's a timeboxed mechanism to help browsers and servers transition to a
(hopefully near) future in which browsers require CT for all certificates.
That means a good chunk of its value is in having it widely deployed within
the next year or so. (I elaborated on this a bit at
Getting it widely deployed as a TLS or X509 extension in that time frame
isn't feasible.

> ....Roy