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

Ryan Sleevi <ryan-ietf@sleevi.com> Thu, 08 August 2019 15:02 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 F40E61200C4 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 8 Aug 2019 08:02:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 LCCy-iyl4mtY for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 8 Aug 2019 08:02:46 -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 18D141200A3 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 8 Aug 2019 08:02:46 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hvjuC-0005X6-8A for ietf-http-wg-dist@listhub.w3.org; Thu, 08 Aug 2019 15:00:40 +0000
Resent-Date: Thu, 08 Aug 2019 15:00:40 +0000
Resent-Message-Id: <E1hvjuC-0005X6-8A@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 <ryan.sleevi@gmail.com>) id 1hvju9-0005WL-97 for ietf-http-wg@listhub.w3.org; Thu, 08 Aug 2019 15:00:37 +0000
Received: from mail-ed1-f42.google.com ([209.85.208.42]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <ryan.sleevi@gmail.com>) id 1hvju7-0000n6-Ob for ietf-http-wg@w3.org; Thu, 08 Aug 2019 15:00:37 +0000
Received: by mail-ed1-f42.google.com with SMTP id m10so91130685edv.6 for <ietf-http-wg@w3.org>; Thu, 08 Aug 2019 08:00:15 -0700 (PDT)
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; bh=fJ0one1R4pAu3pX0jLTKcidpCoGPoFLQLdomFLRMkIk=; b=d6A1uNj6YUSW6cxrrMIURt8/zB/Rje0oNnwgSWY5YjF4nFO/27muNYTxuSas1p1IdI MtI1WvA6TYnFDcCHf9OjOsA7iveduIZ2Ynqg7zjVepQdD+U+zs2InUIqmCsLf94S1pCH 8eOWWUmzHoGJ3itvJOPVMxSk2FV4YLnbDnJouo1jiBsU5wOxbAdQyqZkD4saYwsv4Nwk tcji3BMApqeMdjH7AoU+eGAZJJOl8oBfJbDI13BOg5QY/hYEBNlKUH7lE7sGGlvtPtgU 13vY25KPAvHSRk8YOxUYgTm7jBTsO2LQapqrHfLqtnSQx7JChHgf5kpFOQjY+8m6Nh8q yHNA==
X-Gm-Message-State: APjAAAXG7T15U1ABuHonCxIOaJ68L6v+FXEEUJhDg8tY1AYCmRF2gxSY LXUJIC8NvH6lo6xJxE5TlvKSqcT/
X-Google-Smtp-Source: APXvYqyLWOs8H3Z+1YtYazWrPDFsEtPVN9sYKD3jQ1Up9L2bPIiYg4yjZQdzLNiYHGBkTYe+H4jN4g==
X-Received: by 2002:a17:906:d1d0:: with SMTP id bs16mr14127394ejb.286.1565276413773; Thu, 08 Aug 2019 08:00:13 -0700 (PDT)
Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com. [209.85.128.41]) by smtp.gmail.com with ESMTPSA id r10sm21407253edp.25.2019.08.08.08.00.13 for <ietf-http-wg@w3.org> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Thu, 08 Aug 2019 08:00:13 -0700 (PDT)
Received: by mail-wm1-f41.google.com with SMTP id p74so2728702wme.4 for <ietf-http-wg@w3.org>; Thu, 08 Aug 2019 08:00:13 -0700 (PDT)
X-Received: by 2002:a1c:9c4d:: with SMTP id f74mr4832932wme.156.1565276413209; Thu, 08 Aug 2019 08:00:13 -0700 (PDT)
MIME-Version: 1.0
References: <CAN2QdAED_6C7GmyTSXqTaZHFUYm7GVRWa753WbqrJ7Uf8fwp9w@mail.gmail.com>
In-Reply-To: <CAN2QdAED_6C7GmyTSXqTaZHFUYm7GVRWa753WbqrJ7Uf8fwp9w@mail.gmail.com>
From: Ryan Sleevi <ryan-ietf@sleevi.com>
Date: Thu, 8 Aug 2019 11:00:02 -0400
X-Gmail-Original-Message-ID: <CAErg=HEKVcbCuP=5ROP_mh9-EFuBzXCRTChX6RHOmNim1YD-LQ@mail.gmail.com>
Message-ID: <CAErg=HEKVcbCuP=5ROP_mh9-EFuBzXCRTChX6RHOmNim1YD-LQ@mail.gmail.com>
To: Watson Ladd <watson@cloudflare.com>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="00000000000095b39f058f9c5020"
Received-SPF: pass client-ip=209.85.208.42; envelope-from=ryan.sleevi@gmail.com; helo=mail-ed1-f42.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-0.147, BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1hvju7-0000n6-Ob 4d6b70d6dfa0254f332cc234060f5408
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/CAErg=HEKVcbCuP=5ROP_mh9-EFuBzXCRTChX6RHOmNim1YD-LQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36949
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: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?

>