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

Emily Stark <estark@google.com> Tue, 15 November 2016 01:55 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 BEF401295CA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 14 Nov 2016 17:55:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.998
X-Spam-Level:
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: 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 7qCA5PQl9fz6 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 14 Nov 2016 17:55:38 -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 D23DD12964B for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 14 Nov 2016 17:55:38 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c6SuI-0005KH-Ih for ietf-http-wg-dist@listhub.w3.org; Tue, 15 Nov 2016 01:51:30 +0000
Resent-Date: Tue, 15 Nov 2016 01:51:30 +0000
Resent-Message-Id: <E1c6SuI-0005KH-Ih@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 1c6Su8-0005JW-RK for ietf-http-wg@listhub.w3.org; Tue, 15 Nov 2016 01:51:20 +0000
Received: from mail-it0-f51.google.com ([209.85.214.51]) 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 1c6Su2-0006Mb-OV for ietf-http-wg@w3.org; Tue, 15 Nov 2016 01:51:15 +0000
Received: by mail-it0-f51.google.com with SMTP id c20so118888864itb.0 for <ietf-http-wg@w3.org>; Mon, 14 Nov 2016 17:50:54 -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=gZdJVa9n4kCxULuBD77XQHAKT0wIbpKlP3VelQztrWY=; b=KyOOpdH6yWIDz4Rohr/OMacpEU5JG4bW7+P46mJ0EhhgXa+YYbQf9xa+h25Elzja6P lH6DyiKCWUoIHpVpqpJNrj2QqboHh/jNl8TLrBC4J42cQPusXwGEd4gXTh51lGoxRxrC D6Y7aEby74aCbyJWIcYqveVZ/7rKfJdl4XH8/gva2b6Dotr8SaF6s3UxhwMGgKzhjx2W 2UyAhpjZua3Hjz3xYlOdE/7A1EQdsb4PdVPa58tsRKIKmE5e40SHQ366L9jeoBuCuZH7 9YAw29XFJZnNl5QQv3mo9LEA/OYBZP4uCO3dUKtf78YWNUFVvmp1hZ9njiqMl/hkVlMv FxjA==
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=gZdJVa9n4kCxULuBD77XQHAKT0wIbpKlP3VelQztrWY=; b=L89rmMcVbhEUTrn7kPDqggDuhiC1vmTCvDCyQ6dcBFiwQHa9UIGcCBK5SIpUbrSU98 4swiRX09UJ+EfzGAycTEITJq6xgxHiwjomSsvCEtPEIizsWScFs/D7Dx8muOocZmPs7n wCkFwjHSuw0FH65zAAftJ0gm4s4Jsh7dhrzebSIJfKEKsnOgQhNt8Oc4qPwPO57roMUG gNymqTNG5/3iZ1BImb5S/VIl1ZlBOTfX255Ek0tPlOgXILFVUJvpuHca2QrqR1kr2CGB Rr6VaTfqTA6+M956n6dVCgAPQ6XdwfR4ue+RmEjljKondb22nX3osRym5x8tqRrIOqXF Gn/w==
X-Gm-Message-State: ABUngvcsOMSQUdukW3d2ATG/wWdyQQu8RtpE6i+DLohwIdgCIc4w43mfrHosjt4GTky63lVk6BXlRnPl6Aan44Zx
X-Received: by 10.107.135.219 with SMTP id r88mr27024102ioi.224.1479174648159; Mon, 14 Nov 2016 17:50:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.136.84 with HTTP; Mon, 14 Nov 2016 17:50:27 -0800 (PST)
In-Reply-To: <CABcZeBNuoiqKZQ4eWS6KJnwaeeCVzw6zmozf3T=jQJajgerSVg@mail.gmail.com>
References: <CAPP_2SbEM+_Ynf_Jcf4fUwp142rZ+69nF=dH6G0Tt_izYJC6xA@mail.gmail.com> <CABcZeBNuoiqKZQ4eWS6KJnwaeeCVzw6zmozf3T=jQJajgerSVg@mail.gmail.com>
From: Emily Stark <estark@google.com>
Date: Tue, 15 Nov 2016 10:50:27 +0900
Message-ID: <CAPP_2SZzww0JZDBCLGfK+mT9VDZR6L0iugXXL0xawRJ3Nd_p0Q@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=209.85.214.51; envelope-from=estark@google.com; helo=mail-it0-f51.google.com
X-W3C-Hub-Spam-Status: No, score=-6.0
X-W3C-Hub-Spam-Report: AWL=1.976, 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.799, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1c6Su2-0006Mb-OV 7b4319c1e553660ed3a771d47012db45
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Comments on draft-stark-expect-ct-00
Archived-At: <http://www.w3.org/mid/CAPP_2SZzww0JZDBCLGfK+mT9VDZR6L0iugXXL0xawRJ3Nd_p0Q@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32901
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>

On Tue, Nov 15, 2016 at 6:04 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Sun, Nov 13, 2016 at 9:47 PM, Emily Stark <estark@google.com> wrote:
>>
>> 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.
>
>
> In general, my intuition would be that all these parameters other than
> the policy should be the same. Is there some compelling use case fo
> why they should not?

I think sites will want to roll out HSTS and Expect-CT independently
and gradually. For example sites that already have HSTS enabled with a
long max-age might want to turn on Expect-CT with a short max-age and
gradually increase it. Or vice versa.

Also, this is a bit entangled with the discussion about whether we
need/want includeSubDomains for Expect-CT. If we don't want
includeSubDomains (and I hope that there isn't much demand for it, for
simplicity's sake), then it's confusing that
`Strict-Transport_Security: expect-ct-enforce; includeSubDomains;`
only applies HTTPS upgrades to subdomains and does not apply Expect-CT
to subdomains. If we do want includeSubDomains for Expect-CT, then I
can imagine use cases where HSTS should apply to the entire domain but
not Expect-CT (e.g. a subdomain operated by a third-party which is
HTTPS-enabled but not CT compliant), which suffers from the
aforementioned confusing-ness and also requires a separate
expect-ct-includeSubDomains directive.

>
>
>> > 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
>>
>> (https://groups.google.com/d/msg/mozilla.dev.security.policy/VJYX1Wnnhiw/ZaJBaKfKBQAJ).
>> 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
>> time.
>
>
> The problem is that as written the future is likely to involve a lot of
> bustage.

I feel like maybe I'm not understanding what you'd like to see
instead. Are you arguing that the Expect-CT draft should contain a
policy like "all EE certs must come with 2 SCTs from different logs",
even if that policy differs from what different browsers plan to
actually enforce for new certificates? Or that browsers shouldn't
require CT for all certificates until they standardize on such a
policy?

>
>
>> > 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.
>
>
> Two different independent servers with the same name behind
> a load balancer? Or a server farm where policies are rolled out slowly.
>
> -Ekr
>
>>
>>
>> >
>> > -Ekr
>>
>