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

Emily Stark <estark@google.com> Wed, 30 November 2016 21:42 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CCE129B40 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 13:42:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.896
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMxlvE_SDY1T for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 30 Nov 2016 13:42:43 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0916129A6A for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 30 Nov 2016 13:42:42 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cCCaY-00021w-By for ietf-http-wg-dist@listhub.w3.org; Wed, 30 Nov 2016 21:38:50 +0000
Resent-Date: Wed, 30 Nov 2016 21:38:50 +0000
Resent-Message-Id: <E1cCCaY-00021w-By@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <estark@google.com>) id 1cCCaJ-00020M-G9 for ietf-http-wg@listhub.w3.org; Wed, 30 Nov 2016 21:38:35 +0000
Received: from mail-io0-f173.google.com ([209.85.223.173]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <estark@google.com>) id 1cCCaB-0005Ae-1C for ietf-http-wg@w3.org; Wed, 30 Nov 2016 21:38:30 +0000
Received: by mail-io0-f173.google.com with SMTP id m5so236198095ioe.3 for <ietf-http-wg@w3.org>; Wed, 30 Nov 2016 13:38:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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; d=1e100.net; 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 10.36.52.203 with SMTP id z194mr30748256itz.121.1480541880494; Wed, 30 Nov 2016 13:38:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.63.7 with HTTP; Wed, 30 Nov 2016 13:37:39 -0800 (PST)
In-Reply-To: <401e7f4a-a5aa-b9d5-63a8-b3fbde4e814e@KingsMountain.com>
References: <401e7f4a-a5aa-b9d5-63a8-b3fbde4e814e@KingsMountain.com>
From: Emily Stark <estark@google.com>
Date: Wed, 30 Nov 2016 13:37:39 -0800
Message-ID: <CAPP_2SaCEphi2WQGzddbJ25eLFgMzj6tghjRuihj6-rETYEjfQ@mail.gmail.com>
To: "=JeffH" <Jeff.Hodges@kingsmountain.com>
Cc: IETF HTTP WG <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a113b0716dcfd9b05428b84a8
Received-SPF: pass client-ip=209.85.223.173; envelope-from=estark@google.com; helo=mail-io0-f173.google.com
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: titan.w3.org 1cCCaB-0005Ae-1C d27b0735ede623a5c53c986b4e048d4a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Additional comments on draft-stark-expect-ct-00
Archived-At: <http://www.w3.org/mid/CAPP_2SaCEphi2WQGzddbJ25eLFgMzj6tghjRuihj6-rETYEjfQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33055
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Thanks, Jeff. Replies inline.

On Wed, Nov 23, 2016 at 4:56 PM, =JeffH <Jeff.Hodges@kingsmountain.com>
wrote:

> Here's some additional comments on "Expect-CT"
> <https://tools.ietf.org/html/draft-stark-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 https://github.com/bifurcation/expect-ct/pull/10


>
>
> 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="https://example.org"; 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 https://github.com/bifurcat
ion/expect-ct/pull/11


>
>
> 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.: <https://tools.ietf.org/html/rfc6797#section-14.3>, 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
https://github.com/bifurcation/expect-ct/pull/12


>
> 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 https://tools.ietf.org/html/draft-stark-expect-ct-00#
section-2.3.1 ('If the "max-age" directive has a value of 0...')


>
>
> 6. clarify characteristics of report-only
>
> Emily Stark <estark@google.com> 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
>
>