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

Nick Sullivan <nicholas.sullivan@gmail.com> Mon, 28 November 2016 23:59 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 E0BB212A162 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 28 Nov 2016 15:59:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.497
X-Spam-Level:
X-Spam-Status: No, score=-8.497 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=-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=gmail.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 bymdryU4usXC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 28 Nov 2016 15:59:17 -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 9A8F612A173 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 28 Nov 2016 15:59:17 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cBVlu-0002xt-CE for ietf-http-wg-dist@listhub.w3.org; Mon, 28 Nov 2016 23:55:42 +0000
Resent-Date: Mon, 28 Nov 2016 23:55:42 +0000
Resent-Message-Id: <E1cBVlu-0002xt-CE@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 <nicholas.sullivan@gmail.com>) id 1cBVln-0002x7-Bz for ietf-http-wg@listhub.w3.org; Mon, 28 Nov 2016 23:55:35 +0000
Received: from mail-ua0-f173.google.com ([209.85.217.173]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <nicholas.sullivan@gmail.com>) id 1cBVlf-0005pE-Rs for ietf-http-wg@w3.org; Mon, 28 Nov 2016 23:55:30 +0000
Received: by mail-ua0-f173.google.com with SMTP id 12so161142048uas.2 for <ietf-http-wg@w3.org>; Mon, 28 Nov 2016 15:55:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tO9V/6ejlv9V+SJ3LafSnj0bIQhJqCqklo95FkNfTGE=; b=aTS6yeE2+nmV1bK3xW0m16MIGdFtjDom61WpufapmGTArlrGaoHmuhnD2UpgLtqndc 3yLHcocE4qZiQg9djJgiOE/8m/VhvBYwLxHg6DgyxEDAFyh4EKVna6YCEYlGwKAsipNg 4gZCwzIXby3jOUzAHJo+ysFVCNoIfcLnYrUzJLqSex6yjtXpjjyk+iaHYqH8LMNaRBQL jA/co1unKGMGbvwNFL6kZaNZpZlqbDE3EKumU05M1IhVqB8R7X1JYv9hHUHxbr+WV2T0 wHIhUQmf3etdePmFoS+qywfeILtcKldjhi7qC5+5dO/vKE+hQUG0Ab6gft0Sv+NA4KN/ CyRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tO9V/6ejlv9V+SJ3LafSnj0bIQhJqCqklo95FkNfTGE=; b=m2aoZJewYvIVvJjZ4UUw34XI7Bw4Sa59J4BFLHTyAfZQDB7OGVDn/KLv9Jj5nqTj+7 yif3xW13nq+Kh16XYn1kOlyVSHNIzxxwWizMYD83DdfR1F+BachBImf181wbQf28pjTd i7bRKzh88IvFNYv0IyxJ5yxuma74NR4husOsquGkob2pYoA+nf2grXCuPUbPDgGzUclJ cTQEwXXcuztLzO4ybwQH+iVRXaZxY5PP/Wv+A+Aq3/fEkLOP1IimWc7rXNxhrfCjtxnM 8GfM+PSnPCaTKe0oWQsdMfih2FFbkmZyFsueTAlOHBJaMXH9NsKMKyEXZlREEpPRXlXs SKNg==
X-Gm-Message-State: AKaTC03U51ZJPE+UtvU8NEnRapmfJ3MAZIkqURRkxJH1Phmt7CvnrFEQyHw3NBnJ58/FCrykL9///firtpEn8g==
X-Received: by 10.176.64.196 with SMTP id i62mr18458957uad.70.1480377301323; Mon, 28 Nov 2016 15:55:01 -0800 (PST)
MIME-Version: 1.0
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> <CAPP_2SYaNxzw8Cd9hBEz2RzK5kO8fdR8JxLk9B2Dr+yyGgwkyA@mail.gmail.com> <CABcZeBPKa-xdT6JoHVSQTjuHU5r=K0CL=2UmKrLW3jtf9Mu+uA@mail.gmail.com>
In-Reply-To: <CABcZeBPKa-xdT6JoHVSQTjuHU5r=K0CL=2UmKrLW3jtf9Mu+uA@mail.gmail.com>
From: Nick Sullivan <nicholas.sullivan@gmail.com>
Date: Mon, 28 Nov 2016 23:54:50 +0000
Message-ID: <CAOjisRzp1py-BheYBCyX2yUfrbDKTBDgQoEB=2v0HO1FOwgZGA@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>, Emily Stark <estark@google.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=94eb2c122c2e2dd31005426533c9
Received-SPF: pass client-ip=209.85.217.173; envelope-from=nicholas.sullivan@gmail.com; helo=mail-ua0-f173.google.com
X-W3C-Hub-Spam-Status: No, score=-4.0
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cBVlf-0005pE-Rs 19688a9532276f16a6f78ac74046f5c7
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Comments on draft-stark-expect-ct-00
Archived-At: <http://www.w3.org/mid/CAOjisRzp1py-BheYBCyX2yUfrbDKTBDgQoEB=2v0HO1FOwgZGA@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33029
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>

Cloudflare is considering using this header in report-only mode to help
identify issues in our CT-stapling infrastructure. This data will help us
with future CT decisions.

We would naturally expect report-only and enforce mode to have the same
semantics, which includes caching. Although our CT-stapling and
header-adding infrastructures are de-coupled, there is a use case for
caching report-only headers: load balancing. Our connections are load
balanced, so subsequent connections may not end up on the same server as
the previous connection. Cached enforcement headers would help us catch
issues where both the CT-stapling configuration and the header-adding
configuration failed to run on a server. With caching, it's more likely
that a
that server with a broken CT config will end up handling resumed connection
from a user agent that had previously connected to a properly-configured
server that that had set the header.

Nick

On Fri, Nov 25, 2016 at 11:21 AM Eric Rescorla <ekr@rtfm.com> wrote:

> On Mon, Nov 21, 2016 at 3:28 PM, Emily Stark <estark@google.com> wrote:
>
> 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.
>
>
> I'd in general be interested in hearing from site owners on how they
> feel about this header. That would be a good addition to this discussion.
>
>
> - 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.
>
>
> I'm not sure how strong the analogy is here. It's actually a nontrivial
> inconvenience
> for sites that different browsers have different policies. With that said,
> it's not something
> I'm willing to make a big deal of if the send of the WG is otherwise.
>
> -Ekr
>
>
>
> 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
> >> >>
> >> >
> >
> >
>
>