Re: Call for Adoption: Expect-CT

Eran Messeri <> Tue, 13 December 2016 11:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB91C1295DB for <>; Tue, 13 Dec 2016 03:47:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.396
X-Spam-Status: No, score=-9.396 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, RCVD_IN_SORBS_SPAM=0.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 kQgljcN2LIKx for <>; Tue, 13 Dec 2016 03:47:17 -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 0FC5C1295D2 for <>; Tue, 13 Dec 2016 03:47:16 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cGlVE-0008T8-5M for; Tue, 13 Dec 2016 11:44:12 +0000
Resent-Date: Tue, 13 Dec 2016 11:44:12 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cGlV0-0008SN-GY for; Tue, 13 Dec 2016 11:43:58 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1cGlUu-00026K-Hc for; Tue, 13 Dec 2016 11:43:53 +0000
Received: by with SMTP id u144so22104957wmu.1 for <>; Tue, 13 Dec 2016 03:43:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=XtgySqvMmWtj84YzWPXLg9m4ExxOEy76eCgHcD2vnSk=; b=NI/7y82BY+fLhJtCS2ilkXyiVkU9236h7pY0Isbs+/qMpLe/UFAO1Ay+Nly1wZmdFL EoXhV7DSR1fjOdb4tId6LXH+rVizpKfuh85TczXisUAPkvolYVj1ge7US+csbkFm3dUi ulkYvt66hfcH7CT85+bgUm5Z9sj1qZr2c9Ykepq4PD0b8ZRN4lda00C8pQNMljKxC+1p eWYu/zNLwvmsKhQQx7f2n7a9ZUqH4RZR90r+qHV64cM6N2GXlnx6LWKrcR7L8U3kYJr9 aXcKPS1eSSpjEybJyr7btNpWIdlTMZsSLf7tT0IWU3RATUOKB3+7rwVG3j794IoSVAkr Ma8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XtgySqvMmWtj84YzWPXLg9m4ExxOEy76eCgHcD2vnSk=; b=Oi8NrIivu3WK55gZ5Wpjoo1RVTTPu5cv+bhhUSe+QjwJ89BwpmlxO21C5YKxDKoPyk +WhtOttT8dVJeBGIlTzYhucK3Tgwvv56d3YOqqAXZjfg+xAlwHykGyytL0ydBTAwnQ6z pncyshz3S2v58GGCW6rNoli8aB9gsGXO4LwZD3FL/4tNJNupxX2RxN6LmmWgywRIm9ra vZz2WMUQSQq3gKdbCtkgF5bSXAMk3xr9RtOtxl0fruW3uTaEniuVwmy2O/d3wCeXxV4h 4O5M49i0KSmZCMn1tV/aO5ys3iDOAvYIgewVQIYw8qdVDmaebnb4YHjZ1tgyFRNEO8xr 2Z1g==
X-Gm-Message-State: AKaTC01YiFFyPBQW/Ph787v1eGzPhRUPcRomQsy8JD6dZl2keL5nQRZQgH9vw8EJ74H10kBwqTNgU2AX8HJkp734
X-Received: by with SMTP id l2mr2344005wml.86.1481629405611; Tue, 13 Dec 2016 03:43:25 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 13 Dec 2016 03:42:55 -0800 (PST)
From: Eran Messeri <>
Date: Tue, 13 Dec 2016 11:42:55 +0000
Message-ID: <>
Content-Type: multipart/alternative; boundary="001a114afa2c696340054388ba8d"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-8.6
X-W3C-Hub-Spam-Report: 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-3.099, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1cGlUu-00026K-Hc c985a988c99eb99167cc19b50edfc95e
Subject: Re: Call for Adoption: Expect-CT
Archived-At: <>
X-Mailing-List: <> archive/latest/33160
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

While in theory this could be a TLS option, in practice, with the
infrastructure deployed today, it would be very hard to deploy as a TLS
One of the ways to support Certificate Transparency in an TLS connection is
to send Signed Certificate TImestamp Lists in the TLS handshake (assuming
the client advertises support for it).

Deploying that feature, in Chrome, on Google's infrastructure and
open-source HTTP servers, have taught us that this is a very invasive
change that could break servers (simply by clients re-ordering the TLS
 extensions they support) and is not trivial to deploy (needs support in
the underlying SSL library).

Exactly for this reason a header is, IMHO, a good solution: It is much
easier to set up and would help identify cases where a site owner believes
their site supports CT, but it doesn't (if changing certificate issuance
software / TLS servers was easy, we wouldn't have needed this feature in
the first place).