Re: Comments on draft-stark-expect-ct-00

Emily Stark <> Sun, 13 November 2016 12:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 515071293DB for <>; Sun, 13 Nov 2016 04:52:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.998
X-Spam-Status: No, score=-7.998 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.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 HwnLYWUbedQv for <>; Sun, 13 Nov 2016 04:52:04 -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 D3306128B38 for <>; Sun, 13 Nov 2016 04:52:04 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1c5uCv-0007iF-Rj for; Sun, 13 Nov 2016 12:48:25 +0000
Resent-Date: Sun, 13 Nov 2016 12:48:25 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1c5uCp-0007gm-MN for; Sun, 13 Nov 2016 12:48:19 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1c5uCi-0007eq-RC for; Sun, 13 Nov 2016 12:48:13 +0000
Received: by with SMTP id c20so29999937itb.0 for <>; Sun, 13 Nov 2016 04:47:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=DIdIR7tB0BYvGoWUgAof+ECyqxsNXRwU2RzeT7gu8Hw=; b=cc5H1NRyutzGJBuovMg0TNydwfMQ8E+C4UUm8vLQQsDxLIIA4JZKat/yJO/hVsXfas wg4Wfcop7TZ/wuwvVPKnpXmgUWJ88PhVAqoUvebNW3M2OcTMf+QFpChTlwpYx1fAJThv pU/LAY2XedGHLkFo66mR9Y44ZkctDVmufdwUpKD0pP14FAGYTSUY1OYDCxv/dKmdGsFx jpI85sVCqJAMaCooITW8kjgFYaeNefB/ExA9uKikc9CMOG47kU3wFmsz+M3h0TMEuHVX wiAvW7c6/d+1CAAw0O/IdSmIfsK91G+o44s0xR33cKkO5f4sR6+89JyZs8/1leQFYLL7 RJYg==
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=DIdIR7tB0BYvGoWUgAof+ECyqxsNXRwU2RzeT7gu8Hw=; b=D1zFKhciT2/CNEFONg/fy3V2gTR/TYoDggwEg9Kb2d4PYrqyP9wthKlwuzLbJ9Axlh RHCHzARyzWKa2EwIo3Rq7TlBAFoP7svy4MqkyrQV3qrKAzWjK7ScnUGQge9GE1QsxRtC s2vlXihhZUO8VNjpdwP1GsQQALRZ+/PotA1mMf7RAS85TAZrD8WosM+rxi8BruGsS9LR IuNSZSU2gKfvF/bfZeFSabeOOYzp0aUhD23LQIPMKCKeNNIEOveJoJ9b2sGcuUDyhgMt auWrcJPQe8LM4dhrmLR7HYPqG+Leom389163ME3K7fCS7XOh9KUkDAYRKcr58L0GBvTI s5xg==
X-Gm-Message-State: ABUngvfiWGOE/3imAA0sLKRFAkMuIzA98kMw2UCVqLBTjfNL1jPO9WmvNYihTwf6oVDXHJucrm235bxcfjEqPMf2
X-Received: by with SMTP id o140mr3379384ita.33.1479041266310; Sun, 13 Nov 2016 04:47:46 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 13 Nov 2016 04:47:25 -0800 (PST)
From: Emily Stark <>
Date: Sun, 13 Nov 2016 04:47:25 -0800
Message-ID: <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-6.5
X-W3C-Hub-Spam-Report: AWL=1.634, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1c5uCi-0007eq-RC 84a629006de7551c4afeca73809f47d2
Subject: Re: Comments on draft-stark-expect-ct-00
Archived-At: <>
X-Mailing-List: <> archive/latest/32878
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi, thanks for the comments. Replies inline.

> Overall:
> Is there a reason to not have this be attached to the HSTS header (or,
> I guess more weakly to HPKP)?  The syntax seems like it allows it. It
> seems like we go to all the trouble of making these headers extensible
> (indeed, the syntax in S 2.1) seems almost identical to HSTS but then
> we define a new header each time.

If we try to attach it to HSTS or HPKP, the syntax gets kind of
clunky, which according to my understanding is one of the main reasons
that HPKP ended up as a separate header too. For example, one might
want separate max-ages for HSTS and Expect-CT, and one might want to
configure a report-uri but it should be clear that the report-uri
applies to Expect-CT but not to HSTS, and then you end up with
something like this:

Strict-Transport-Security: max-age=31536000; expect-ct-enforce;
expect-ct-max-age=86400; expect-ct-report-uri=https://...

which I don't think would be the end of the world, but it does feel
kind of clunky and error-prone to me.

> At least, it would be nice to merge the report-uri function/description.
> I am probably missing something, but I don't see the text that defines
> what the actual semantics of enforcing CT are. The document says stuff
> like "The UA evaluates each connection to an Expect-CT host for
> compliance with the UA's Certificate Transparency (CT) policy" which
> leads me to believe that different UAs might have different policies.
> Assuming I am correct, this seems like a recipe for interop problems,
> even with the compliance checking in S 2.3.1. Consider the case where
> a UA's policy is that you must have CT for every cert in the chain
> and the operator has two certs, one from a CA which has CT for every
> cert in the chain and another from a CA which has CT just for the EE
> cert. If the client gets Expect-CT from a host with the first cert,
> then it will fail trying to connect to a host with the second cert.

It is indeed the intention that different UAs can have different
policies. I think this reflects the reality that browser are not
necessarily planning to have identical CT policies
That is, eventually, when browsers require CT for all certificates,
site owners will have to face this same problem of making sure that
all their certificate chains are compliant with the CT policies of all
the UAs that they care about. So I guess I see the interop problem as
somewhat separate, perhaps something that should be addressed on its
own when the CT ecosystem and implementations have matured enough that
UAs are able to standardize on one policy...?

To put it another way, 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), and the future is quite possibly
different policies in different browsers, at least for some amount of

> S 2.1.3.
> What's the rationale for not caching the directive in report-only mode.
> If the purpose of the report-only mode is to tell you when you have
> nonconforming servers, then don't you want to be able to turn it on
> on server A and detect hwen server B is broken? That seems like it
> doesn't work if you don't cache.

I'm tempted to say "because that's how HPKP does it", but that's
probably not the answer you're looking for. :) I'd expect that sites
would generally serve the report-only header on all responses
unconditionally. I can't really think of a common misconfiguration
scenario that would cause a CT violation and would *also* cause the
header to not be served, but maybe that's a failure of imagination on
my part.

> -Ekr