Re: Additional comments on draft-stark-expect-ct-00

Emily Stark <> Wed, 30 November 2016 21:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6CCE129B40 for <>; Wed, 30 Nov 2016 13:42:45 -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 ZMxlvE_SDY1T for <>; Wed, 30 Nov 2016 13:42:43 -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 D0916129A6A for <>; Wed, 30 Nov 2016 13:42:42 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cCCaY-00021w-By for; Wed, 30 Nov 2016 21:38:50 +0000
Resent-Date: Wed, 30 Nov 2016 21:38:50 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cCCaJ-00020M-G9 for; Wed, 30 Nov 2016 21:38:35 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1cCCaB-0005Ae-1C for; Wed, 30 Nov 2016 21:38:30 +0000
Received: by with SMTP id m5so236198095ioe.3 for <>; Wed, 30 Nov 2016 13:38:06 -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=Hw57cGymUzlGAaEurMY86wF4bNJVKq5JzetaDjjvFwo=; b=aTuIxaqddYSKtzXOTBQxQB8NFlrCEP4CetLjWhKGrx9oUkgpa6Qu0JN7PdKJ2swIOx 169AzEuzFl2laR+x+HFTxC9yml8MChRdYOYWOi57Hw2qPOw67H7cCd8vkEnAmFg5mC6m zkFnhA9wqKT4RLMN4o0SwsSNM95wHd+uSkaxkkxLr01DqLTr1qJ/dGLTVBzVlA7VoCjm zB+i8gGJI6vwbYacZm0aLOi8sTkEPKLkwAV+sclTUuceTI0xZ+0tPy21WrpAWyXhBKAQ /F8YxG2jIimTZ/Tn6I2lS6XhZT4uwejBp6dAUCgYbVlOYWBf6lFW6mRMsH4DZ0yOKuki GmKw==
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=Hw57cGymUzlGAaEurMY86wF4bNJVKq5JzetaDjjvFwo=; b=ioJulwyNXGod43pHDwweCF5mKPOX68KCbVIN9yo5uGteB2U1mygx5Wl5oJrBROi0Pd qqgXKIukGhGT8Z8DwTkCDIhtx9VDZlXnXGuI/UBZSaMuEZ0LcR9TLq7L8Thxx9uTLiXx i6fVismwLYbgEHCN5X5QPSNoYS1SXITxU02BFdefelInwcfgjWAo7a55ofSkf7kd4d+v ip5tWb4nkBPLmrpMewp8iZOT/jMTA1xAeQyqqHtv7rPRqBOB6rrfJfNEFng+TpkYW7Z5 /tgTlKfRioI7F9XqG/EQHfk3fg6LDNFDJSIsS3YasEH+gJ7vgeXuYevoEMdmN6BJyB4P Kw9Q==
X-Gm-Message-State: AKaTC00mJFSizNuubRSOeaTF1Nlx1qznPY+3jdOG2XALdVo5NGj1oqk/ZG8/kJJhN2kY3picm1vLRInxd9oJPdLz
X-Received: by with SMTP id z194mr30748256itz.121.1480541880494; Wed, 30 Nov 2016 13:38:00 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 30 Nov 2016 13:37:39 -0800 (PST)
In-Reply-To: <>
References: <>
From: Emily Stark <>
Date: Wed, 30 Nov 2016 13:37:39 -0800
Message-ID: <>
To: =JeffH <>
Content-Type: multipart/alternative; boundary="001a113b0716dcfd9b05428b84a8"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.8
X-W3C-Hub-Spam-Report: AWL=2.052, 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.899, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1cCCaB-0005Ae-1C d27b0735ede623a5c53c986b4e048d4a
Subject: Re: Additional comments on draft-stark-expect-ct-00
Archived-At: <>
X-Mailing-List: <> archive/latest/33055
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Thanks, Jeff. Replies inline.

On Wed, Nov 23, 2016 at 4:56 PM, =JeffH <>

> Here's some additional comments on "Expect-CT"
> <>
> HTH,
> =JeffH
> In the below, "the I-D" refers to the above I-D.
> 1. Spec title
> Having a title of "HTTP Expect-CT" (HECT) would be more accurate
> because, like HSTS and HPKP, the mechanism is particular to HTTP (and
> actually HTTP-over-secure-transport)

Addressed in

> 2. Expect-CT header field syntax
> The behavior of a valueless Expect-CT header field is presently not
> defined, although it is syntactically correct: both 'enforce' and
> 'report-uri' are OPTIONAL, and 'max-age' is only REQUIRED if 'enforce'
> is present. In HSTS [RFC6797], a valueless strict-transport-security
> header field violates the syntax (because 'max-age' is always required)
> and thus is explicitly ignored.

Good point -- I think this issue will go away as I rework the document to
cache report-only headers, at which point max-age will be required.

> Also, the Expect-CT syntax presently defines the below as a valid
> Expect-CT header field..
>  Expect-CT: enforce; report-uri=""; max-age=86400
> ..which will ostensibly not yield "report-only" behavior, i.e., UA's
> CT-policy will be enforced AND will submit reports of violations of "the
> UA's CT policy". Is that directive combination intended? If so, perhaps
> this might be termed an "enforce-and-report" expect-ct policy.

Yes, that combination is intended. Clarified in

> 3. Terminology
> The I-D does not have terminology of "known expect-ct host" (as in HSTS &
> HPKP) ?
> "known/unknown" can be a useful distinction and spec-writing shorthand,
> see e.g.: <>, the parag
> after the two bulleted parags. I.e. a host can be an "expect-ct host" but
> be unknown as one from the perspective of a particular UA instance.
> The I-D could use a terminology section tho I note HPKP [RFC7469] does
> not have one.
Added a Terminology section and use of Known Expect-CT Host in

> 4. Is expect-ct policy host-wide or connection-specific?
> Is expect-ct policy host-wide, a la HSTS - i.e., applied to all ports
> on a host? Or is it specific to just that particular secure transport
> connection over which the Expect-CT header field was received?  If it is
> connection-specific, should not the port be explicitly part of the
> storage model, as well as the host's domain name?
> The I-D implies that expect-ct policy is connection-specific, and that
> makes sense to me because it is specific to characteristics of the server's
> certificate returned on that connection. It would be good to explicitly
> state this.

It's currently defined host-wide, which matches HPKP and I think is the
simplest thing to do. (I don't anticipate there being much of a use case
for keying by host+port.) I feel like this is reasonably clear from the
fact that the draft refers to Expect-CT hosts throughout and keys by domain
names, but let me know if there are any places where you think it would be
helpful to clarify this.

> 5. server-initiated expect-ct policy deletion?
> Is there no "max-age=0" ability for an Expect-CT host to signal a UA to
> remove it from the UA's Expect-CT cache?

There is; it's in
section-2.3.1 ('If the "max-age" directive has a value of 0...')

> 6. clarify characteristics of report-only
> Emily Stark <> wrote on Monday, November 21, 2016
> at 3:28 PM:
>> - Caching in report-only mode: I can be convinced that this is
>> useful, in case where you are e.g. rolling out a CT-compliant
>> certificate in conjunction with Expect-CT (for example if you have a
>>  config that turns on CT and also turns on Expect-CT in report-only
>> mode, and the config didn't make it out to a few of your servers).
>> Will be especially convinced if site owners say that this is how they
>> want it to work.
> I am thinking that it would be useful to cache report-only expect-ct
> policies, e.g. to satisfy the above use case.
> Thus max-age would be required in the header field value whether either
> or both report-uri and enforce directives are present. (see #2)
> And then we can have max-age=0 be the policy deletion mechanism :) (see
> #5).

> 7. User agent and server implementation advice, sec cons
> The I-D might have similar UA and server implementation
> advice/considerations, as well as security considerations, as HSTS
> and/or HPKP. Something to think about, though I note HPKP does not
> feature distinct UA and server implementation advice/considerations
> sections, though it does have a distinct "privacy considerations" section
> which HSTS lacks.

Acknowledged #6 and #7 but haven't actually done them quite yet.

> end