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

Emily Stark <estark@google.com> Mon, 21 November 2016 23:32 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 88215128874 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 21 Nov 2016 15:32:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.498
X-Spam-Level:
X-Spam-Status: No, score=-8.498 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, 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 O5HiLAFpK3pL for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 21 Nov 2016 15:32: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 11D63127078 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 21 Nov 2016 15:32:37 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c8y1P-0001LY-Qk for ietf-http-wg-dist@listhub.w3.org; Mon, 21 Nov 2016 23:29:11 +0000
Resent-Date: Mon, 21 Nov 2016 23:29:11 +0000
Resent-Message-Id: <E1c8y1P-0001LY-Qk@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <estark@google.com>) id 1c8y1I-0001Kb-Rg for ietf-http-wg@listhub.w3.org; Mon, 21 Nov 2016 23:29:04 +0000
Received: from mail-io0-f180.google.com ([209.85.223.180]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <estark@google.com>) id 1c8y1C-00081H-GC for ietf-http-wg@w3.org; Mon, 21 Nov 2016 23:28:59 +0000
Received: by mail-io0-f180.google.com with SMTP id x94so54113302ioi.3 for <ietf-http-wg@w3.org>; Mon, 21 Nov 2016 15:28:38 -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=3Xt2xtaYl5kQbnjqBPgeAy4Jot/3ywqJMyrSfSbeJnE=; b=hL4am+Yn2foRuqjniL1W8QULZbAq+k0iGE5Bw6X3ClYYp0c+cSoUFEPEDfApP53/XU +uJQLKv4PzwEQGOg6hXJtKmZ+lwR3CYwzRDuqPhfmxSBZKRUMpHzaH9baIUQOooGJFbu FJRlCSZCHmdW7z2QHHvE8zGHtCZpaUYJjmXzGcw7PWahfaIEhqKEupU6/fAJg9IDYrT4 0bEcr4akKX+OS+MH2L0T+VQIlC+rlUYLvNGCgv/doofcp80ijSaJ20tbOJbWE4TzzDY3 vv/IyOqeG5S4TS+TWh/9gFK8pKQEi/wgWCa6/OxBoqsWuy/3G+FoTqKx3cfYZXFB4Rt1 56Lw==
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=3Xt2xtaYl5kQbnjqBPgeAy4Jot/3ywqJMyrSfSbeJnE=; b=BSVwDJP68MKaYyNnQ2n1f0hXtFuLGYbDi1ijflEWzkm5bo1bQ6WRbvztxSLLj7B7Fo G+sZbpqintbVZBUfx9tJH8zORBp7sTPNyRELg2i93jO8KduoIHiDOcBwWs9+8yk8Ac9N 7xNDM4y6l/bUnz/d+HoOIcWElqYTfkD1u5gYDlWc0FuewV+QIJ3rQ0CMujnCZQ1JhejK MToO3pyrVPsxdkXfKEKFK3C3tp06Lfw2f2ZXUVOLo7OmtWbLssi1vhn/2dHZH/sIVhgJ 7fNp0JtDpIOl3UMwRiK9nogcXMZwZXGZ50jEttMOJdvaJcr5lnlor1Y0rMMUHh0EJSUg TqPA==
X-Gm-Message-State: AKaTC00K4W129P80tLOvMvxafVnADtTftuOHhL3zTkgFVo+ZhxefW1Wp2ZoD3t/hVxfVFJnNXJT9g/DwJURYZosC
X-Received: by 10.107.10.11 with SMTP id u11mr13749852ioi.29.1479770912268; Mon, 21 Nov 2016 15:28:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.136.84 with HTTP; Mon, 21 Nov 2016 15:28:11 -0800 (PST)
In-Reply-To: <CABcZeBMz7mOdYLs1WPj+K-YdLJcmn1jEcvbUNe5VD3zA5B90aw@mail.gmail.com>
References: <CAPP_2SbEM+_Ynf_Jcf4fUwp142rZ+69nF=dH6G0Tt_izYJC6xA@mail.gmail.com> <CABcZeBNuoiqKZQ4eWS6KJnwaeeCVzw6zmozf3T=jQJajgerSVg@mail.gmail.com> <CAPP_2SZzww0JZDBCLGfK+mT9VDZR6L0iugXXL0xawRJ3Nd_p0Q@mail.gmail.com> <CABcZeBMz7mOdYLs1WPj+K-YdLJcmn1jEcvbUNe5VD3zA5B90aw@mail.gmail.com>
From: Emily Stark <estark@google.com>
Date: Mon, 21 Nov 2016 15:28:11 -0800
Message-ID: <CAPP_2SYaNxzw8Cd9hBEz2RzK5kO8fdR8JxLk9B2Dr+yyGgwkyA@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.223.180; envelope-from=estark@google.com; helo=mail-io0-f180.google.com
X-W3C-Hub-Spam-Status: No, score=-6.0
X-W3C-Hub-Spam-Report: AWL=1.966, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.999, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1c8y1C-00081H-GC 7fbfcd2e8a4765e3ba40b0af848430c2
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_2SYaNxzw8Cd9hBEz2RzK5kO8fdR8JxLk9B2Dr+yyGgwkyA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32950
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>

Summarizing some hallway conversations from IETF:

- 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.

- Policy: One can draw an analogy to HSTS, where a site promises to
provide a certificate that is valid according to the client's
definition of valid, including factors that vary across clients
(variations in trust stores, SHA1 deprecation, etc.). In practice, I
don't think CT will be more of a foot-gun than HSTS (and certainly
much less than HPKP) because browsers are in close collaboration to
work out policies that play nicely with each other.

On Mon, Nov 14, 2016 at 8:53 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> On Tue, Nov 15, 2016 at 10:50 AM, Emily Stark <estark@google.com> wrote:
>>
>>
>> >>
>> >> (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?
>
>
> I'm arguing that we shouldn't define a header that says "you must enforce
> CT"
> without defining what "enforce CT" means.
>
> -Ekr
>
>>
>> >
>> >
>> >> > 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
>> >>
>> >
>
>