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

Eric Rescorla <ekr@rtfm.com> Mon, 14 November 2016 21:09 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 04A5A12946B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 14 Nov 2016 13:09:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.897
X-Spam-Level:
X-Spam-Status: No, score=-7.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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=rtfm-com.20150623.gappssmtp.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 zmLj38gzYFO5 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 14 Nov 2016 13:09:36 -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 C61B812948C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 14 Nov 2016 13:09:36 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1c6OS3-00019S-Px for ietf-http-wg-dist@listhub.w3.org; Mon, 14 Nov 2016 21:06:03 +0000
Resent-Date: Mon, 14 Nov 2016 21:06:03 +0000
Resent-Message-Id: <E1c6OS3-00019S-Px@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 <ekr@rtfm.com>) id 1c6ORw-00018b-Hd for ietf-http-wg@listhub.w3.org; Mon, 14 Nov 2016 21:05:56 +0000
Received: from mail-yw0-f171.google.com ([209.85.161.171]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <ekr@rtfm.com>) id 1c6ORq-0000ew-6c for ietf-http-wg@w3.org; Mon, 14 Nov 2016 21:05:51 +0000
Received: by mail-yw0-f171.google.com with SMTP id a10so77963674ywa.3 for <ietf-http-wg@w3.org>; Mon, 14 Nov 2016 13:05:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tK1E/pH+VBiwlc9HErcjC3v8GuAJGLH5NoM7VFW4Mgg=; b=BohYQlDWL+KFEWNF2PNTIt7yeNduk549LcoVH+v5g4nB9IMw4bb6s4WKnVigYG5/3F /t7ocRMt/UYBrQ8HLqHXQ/n5BUGkNNQeRtFanQ+V7Mnh7S4L+UJzQpFt1sTtyrr//5iF pcuc3wziiKA8yWEmUPhGPDjNykM/kHastHQNrUCBabSZEfpPIYgkM2ayKeGydGbLb+vg sgB5xcz9w8ki4OAJDCz0BP8qbaddra69DJRIPk0imqXjKSF9wJoSftsI8eZyFJIKi06a gJU4+NvbkVTZEPvrldKj2ldixJtcrc+l+x/Eanl6xBxOHjn3AO5gg8UgWuZVj9ECqgiG 6BzQ==
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=tK1E/pH+VBiwlc9HErcjC3v8GuAJGLH5NoM7VFW4Mgg=; b=MY3LVvsjBfuuRmaNafzlkQbWb2M3bHY/h22YRU6XgV4B6MI8rX/3BbiQUyGvH2A8uZ 0P3DwMQS06oL7+xNHiJB4nHltBv4EUOxc7KcfnPk+YOzAtqO6QTRo7bloPXgHqTo0fWq DjX3qdV4arEF+war2gmEMytgJBPAIpYykCxh/FmNBQ8MZl7crAURcJkz8S4LIATXyYTa ox+hs4KcI4PQjjInzIuQ1Cvhxhg+Moe2dm6CsmSe0L0A3WQs16sWvVrglyRpfQ68CZ5c H0LqCjiKZmXTGKB/ZqpgbQpy+P9BfbI+Mj17YdZEYQsynQSes6KdNO6ZtQoCVWsfookR quvQ==
X-Gm-Message-State: ABUngvdyGw7ukgczXCkmjV7s+DDlffJbGPiq8ysXX6TvpB9g0JOJELksGQVvCd9rzkMk3lIzGChgq10t4MZFKQ==
X-Received: by 10.129.108.216 with SMTP id h207mr16411616ywc.52.1479157524008; Mon, 14 Nov 2016 13:05:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.159.141 with HTTP; Mon, 14 Nov 2016 13:04:43 -0800 (PST)
In-Reply-To: <CAPP_2SbEM+_Ynf_Jcf4fUwp142rZ+69nF=dH6G0Tt_izYJC6xA@mail.gmail.com>
References: <CAPP_2SbEM+_Ynf_Jcf4fUwp142rZ+69nF=dH6G0Tt_izYJC6xA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 15 Nov 2016 06:04:43 +0900
Message-ID: <CABcZeBNuoiqKZQ4eWS6KJnwaeeCVzw6zmozf3T=jQJajgerSVg@mail.gmail.com>
To: Emily Stark <estark@google.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a114dd36ec9484c05414932f2
Received-SPF: none client-ip=209.85.161.171; envelope-from=ekr@rtfm.com; helo=mail-yw0-f171.google.com
X-W3C-Hub-Spam-Status: No, score=-6.0
X-W3C-Hub-Spam-Report: AWL=-0.597, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1c6ORq-0000ew-6c 1313a30656acb1d1872d293beba8a88b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Comments on draft-stark-expect-ct-00
Archived-At: <http://www.w3.org/mid/CABcZeBNuoiqKZQ4eWS6KJnwaeeCVzw6zmozf3T=jQJajgerSVg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32898
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 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?


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


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