Re: Comments on draft-ietf-httpbis-http2-secondary-certs-04

Watson Ladd <watson@cloudflare.com> Thu, 08 August 2019 22: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 897201200F8 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 8 Aug 2019 15:59:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.201, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 56qah_fGLH9H for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 8 Aug 2019 15:59:15 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B687120154 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 8 Aug 2019 15:59:15 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hvrLr-00041l-Dg for ietf-http-wg-dist@listhub.w3.org; Thu, 08 Aug 2019 22:57:43 +0000
Resent-Date: Thu, 08 Aug 2019 22:57:43 +0000
Resent-Message-Id: <E1hvrLr-00041l-Dg@frink.w3.org>
Received: from mimas.w3.org ([2603:400a:ffff:804:801e:34:0:4f]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <watson@cloudflare.com>) id 1hvrLo-00040z-Mf for ietf-http-wg@listhub.w3.org; Thu, 08 Aug 2019 22:57:40 +0000
Received: from mail-qk1-x743.google.com ([2607:f8b0:4864:20::743]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <watson@cloudflare.com>) id 1hvrLm-0000pY-H0 for ietf-http-wg@w3.org; Thu, 08 Aug 2019 22:57:40 +0000
Received: by mail-qk1-x743.google.com with SMTP id 201so70189553qkm.9 for <ietf-http-wg@w3.org>; Thu, 08 Aug 2019 15:57:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=YoQmzFWHFRKfwyX94zfu1WJM4dvSBuBT4LPaBvle5Bg=; b=ZiQv34jjytqwcluGbrbX9my9sy5n2Ozjs54tmlG2DgrIzhJGTMzHNfQF9YcSejvGpa UFFpaAsQWtJuIEZkB20thoc/YLDKEGL2eTeNAnd+yYULxe8zqcTLmrKLSnbJRgg2rZw1 7/5n2atCDIbroML7d11F/BjFbo9Y/N7CW9pn0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YoQmzFWHFRKfwyX94zfu1WJM4dvSBuBT4LPaBvle5Bg=; b=SBoc1PzrqWPwyNTsd1YEv8sSmTZcNtNw9aYzW/6pXNLBHUpc3hf2xfrHzqeME21l9k hiBwZpy3qNewOHJGA4T7SxARSI1xgrhlGjYonAvcUEYuiufIUnbLTZG9sue7nb+CsJrF GvHX33x1v0ir6DfpxFRCoz585X1tP1OKNwCa7z7v8nbhrMWVQEjxk9iIN8DePdVHv/Ha r63wI07EOHuTCeppvCDWaxGIJWV5cOA2gpltuJnOkAhFJvMNdh/t/opxvaf+eG5gMBpG qJR1YNGU7WBCa1xxZllaJMIzC6AEbco7xFM3we/+sK8no/6whAktQvwM6NdcErXDYaeY t5Bw==
X-Gm-Message-State: APjAAAW/d0uUuAyn19pQRPicpDUeuNP0tg/JdAAFCSoyTlDuTf58ksDM qStl8hxbMdIyW8sULcPHAL1/cg9KdHCRy/quMjXJFBd+o6E=
X-Google-Smtp-Source: APXvYqw/q99XtepkX+hx+9LrGrMKW6GkMhMkAiNYPScqQON42rNsZp2/Ej+Xr7gCcSi+OJi361gyGzNSPpTgjPbNpK4=
X-Received: by 2002:a37:68ce:: with SMTP id d197mr10582632qkc.16.1565305037241; Thu, 08 Aug 2019 15:57:17 -0700 (PDT)
MIME-Version: 1.0
References: <CAN2QdAED_6C7GmyTSXqTaZHFUYm7GVRWa753WbqrJ7Uf8fwp9w@mail.gmail.com> <CAErg=HEKVcbCuP=5ROP_mh9-EFuBzXCRTChX6RHOmNim1YD-LQ@mail.gmail.com> <CAN2QdAEt2AD1QUQ=EYkN696hbMCa9dpOKJd+dxDUFxNoHTrtZQ@mail.gmail.com> <CAErg=HGrbsKgrH_Xwk0PXXe1OeaVgOxBz2-F3CC4niEnbwT0Eg@mail.gmail.com>
In-Reply-To: <CAErg=HGrbsKgrH_Xwk0PXXe1OeaVgOxBz2-F3CC4niEnbwT0Eg@mail.gmail.com>
From: Watson Ladd <watson@cloudflare.com>
Date: Thu, 08 Aug 2019 15:57:06 -0700
Message-ID: <CAN2QdAGyPvd_SiLHFfgnPbS=dNENGb17UA5bVfu=WY6keRshiQ@mail.gmail.com>
To: Ryan Sleevi <ryan-ietf@sleevi.com>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=2607:f8b0:4864:20::743; envelope-from=watson@cloudflare.com; helo=mail-qk1-x743.google.com
X-W3C-Hub-Spam-Status: No, score=-4.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1hvrLm-0000pY-H0 1d61f673bd1d1ed3cc0aa297652e466d
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Comments on draft-ietf-httpbis-http2-secondary-certs-04
Archived-At: <https://www.w3.org/mid/CAN2QdAGyPvd_SiLHFfgnPbS=dNENGb17UA5bVfu=WY6keRshiQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36956
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: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Thu, Aug 8, 2019 at 3:54 PM Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
>
>
>
> On Thu, Aug 8, 2019 at 6:26 PM Watson Ladd <watson@cloudflare.com> wrote:
>>
>> On Thu, Aug 8, 2019 at 8:00 AM Ryan Sleevi <ryan-ietf@sleevi.com> wrote:
>> >
>> >
>> >
>> > On Thu, Aug 8, 2019 at 8:27 AM Watson Ladd <watson@cloudflare.com> wrote:
>> >>
>> >> Section 6.4 seems a little strong to me: it's unlikely that $CDN will claim control of all origins it could claim authority over on a connection, but more likely that it does so for ones in subrequests, link headers etc..
>> >
>> >
>> > From a security considerations point of view, isn't it more useful to describe how it potentially could be abused or misused, rather than assume how it's likely to be used?
>> >
>> > That is, is the argument that the Security Considerations should be guidelines for servers deploying it, rather than clients implementing it? The lack of in-step synchronization with DNS seems incredibly important to implementor's security assumptions, and thus important to call out, so I'm curious which bit is seen as a little strong?
>>
>>
>> For benefit of those who  haven't read the draft, permit me to quote
>> from the document:
>>
>> > After the owner of the domain has redirected traffic elsewhere by
>> >  changing the CNAME, new connections will not arrive for that origin,
>> > but connections which are properly directed to this provider for
>> > other origins would continue to claim control of this origin (via
>> >  ORIGIN frame and Secondary Certificates).  This is proper behavior
>> >  based on the third-party provider's configuration, but would likely
>>  > not be what is intended by the owner of the origin.
>>
>> This is not inevitable, as 'would' seems to indicate, but rather
>> possible, as 'could' would indicate, and depends on what the third
>> party prover (third party to whom?) has configured, which in some
>> cases will depend on the customer (entirely possible it is opt-in? Who
>> knows what will happen). This doesn't seem to be clearly relevant to
>> HTTP clients as written, vs. 6.1 which discusses the lack of DNS
>> hijacking need to exploit a stolen certificate.
>
>
> Do you know of many cloud providers/CDNs that start rejecting configurations the moment their customers point their DNS records elsewhere?
>
> I’m unaware of a single one; certainly, unless they did so, this situation does seem an inevitability. For example, I’m similarly unaware of cloud providers today that both provision certificates for their customers and actively revoke certificates when their customers point their DNS elsewhere, which is currently required of all Subscriber Agreements with any publicly trusted CA. Last year, research was shared to that effect, under the name BygoneSSL, showing that it is rarely practiced.

I don't see how revocation is necessary. If the certificate frame is
never sent by the server, or even if it is sent, once the TCP
connection is restarted and the frame is not sent again, the
connection is not reused. Why would the mere existence of a valid
certificate lead to it getting used in a certificate frame?

>
> I see the distinction with 6.1 as being the difference between malice and ignorance, but both share security consequences that implementors - on both sides - should be aware of. Simply highlighting the malicious case seems to do a disservice for the far more likely case resulting in ignorance (of DNS changes by the DNS holder) that would lead a CDN/Cloud Provider to inappropriately advertise, on the basis that it has not yet revoked its certificate.