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

Watson Ladd <watson@cloudflare.com> Thu, 08 August 2019 22:28 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 01D8012003E for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 8 Aug 2019 15:28:32 -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 ZugPKcguXsE9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 8 Aug 2019 15:28:30 -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 6A15B12002F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 8 Aug 2019 15:28:30 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hvqrs-0000iP-WB for ietf-http-wg-dist@listhub.w3.org; Thu, 08 Aug 2019 22:26:45 +0000
Resent-Date: Thu, 08 Aug 2019 22:26:44 +0000
Resent-Message-Id: <E1hvqrs-0000iP-WB@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <watson@cloudflare.com>) id 1hvqrq-0000hc-AN for ietf-http-wg@listhub.w3.org; Thu, 08 Aug 2019 22:26:42 +0000
Received: from mail-qt1-x831.google.com ([2607:f8b0:4864:20::831]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <watson@cloudflare.com>) id 1hvqrp-00026v-1f for ietf-http-wg@w3.org; Thu, 08 Aug 2019 22:26:42 +0000
Received: by mail-qt1-x831.google.com with SMTP id v38so1557627qtb.0 for <ietf-http-wg@w3.org>; Thu, 08 Aug 2019 15:26:20 -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=HxezBgcc2WTFuQNzwPSBPHQziCja1Nxq5JGnRihJXks=; b=b2vx9Myr6jvUEeSjUjSTYvcCQSXE2AwAcD3jdlZcGqJmDrh9PELJRbANniMws9Iv0o SMqbTUqste5I7h8boucIy1cHZbNC8lY2imSRY68AdE1LEx/maqG82KYj8VQ929YDDVKE QpWZ5uJHb2veFMs9csjxv4AAefzSl/5YkfePk=
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=HxezBgcc2WTFuQNzwPSBPHQziCja1Nxq5JGnRihJXks=; b=gaZAscFXY0YzFyvAu6y2LayWF7nRWXhiHSm0RDYgNLJ/okrNWkINtsldDCZntuHdxj C/3MB+HV2n7VOPCl883l4xcDSNyKncK4rQDNCRygCiiLkZqw1092DIRgCKVSGo9Qelqs 2HENd7lHP/Bxn9NvQqE74Rr+juCRHQIv34BWEonNtJQtjkALj8sH8/+5ZhvsHGtOE95P kUj9yrWKUIFlxT4YVWUadrmacGHixiFeGPMbslnJT04Qhwb0CHbdZu8daM2/9jpo6+y8 qc1n+8w8O1khcHMlJoYHZZ9XOi7Ea6RJlEnPumDfv7AWhet2roc/Yu+9cWKKVTuFpjYp 3cvw==
X-Gm-Message-State: APjAAAVXul6Ti5UNoO3RJmEe3jK9MEo+mp7z95z8eBki+SfQirbFGOwG qL7mMDSdDup+D+H6lAiBrRU2Vcd6047JxNYFJH94scI261U=
X-Google-Smtp-Source: APXvYqzo5oizW37jSq0I8aX1dVu8MY+YYCh9ZPBleOqzNyCcU/7QgTeE8UTsFSfGd9HTaSjqbkW66woxPzqCTQFdL6g=
X-Received: by 2002:ac8:4a83:: with SMTP id l3mr224858qtq.46.1565303179672; Thu, 08 Aug 2019 15:26:19 -0700 (PDT)
MIME-Version: 1.0
References: <CAN2QdAED_6C7GmyTSXqTaZHFUYm7GVRWa753WbqrJ7Uf8fwp9w@mail.gmail.com> <CAErg=HEKVcbCuP=5ROP_mh9-EFuBzXCRTChX6RHOmNim1YD-LQ@mail.gmail.com>
In-Reply-To: <CAErg=HEKVcbCuP=5ROP_mh9-EFuBzXCRTChX6RHOmNim1YD-LQ@mail.gmail.com>
From: Watson Ladd <watson@cloudflare.com>
Date: Thu, 8 Aug 2019 15:26:09 -0700
Message-ID: <CAN2QdAEt2AD1QUQ=EYkN696hbMCa9dpOKJd+dxDUFxNoHTrtZQ@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::831; envelope-from=watson@cloudflare.com; helo=mail-qt1-x831.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: titan.w3.org 1hvqrp-00026v-1f 2d5e37b4e5c2fe06af677b71a74555de
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/CAN2QdAEt2AD1QUQ=EYkN696hbMCa9dpOKJd+dxDUFxNoHTrtZQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36953
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 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.