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

Watson Ladd <watson@cloudflare.com> Thu, 08 August 2019 12:26 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 42237120178 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 8 Aug 2019 05:26:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.201, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 ssrzHfYnOutE for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 8 Aug 2019 05:26:51 -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 3E41E1202B1 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 8 Aug 2019 05:26:50 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hvhSe-0004aV-N9 for ietf-http-wg-dist@listhub.w3.org; Thu, 08 Aug 2019 12:24:04 +0000
Resent-Date: Thu, 08 Aug 2019 12:24:04 +0000
Resent-Message-Id: <E1hvhSe-0004aV-N9@frink.w3.org>
Received: from uranus.w3.org ([128.30.52.58]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <watson@cloudflare.com>) id 1hvhSX-0004Yr-SX for ietf-http-wg@listhub.w3.org; Thu, 08 Aug 2019 12:23:57 +0000
Received: from www-data by uranus.w3.org with local (Exim 4.89) (envelope-from <watson@cloudflare.com>) id 1hvhSX-0008T5-NW for ietf-http-wg@listhub.w3.org; Thu, 08 Aug 2019 12:23:57 +0000
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 1hvVRU-0004oG-TP for ietf-http-wg@listhub.w3.org; Wed, 07 Aug 2019 23:34:04 +0000
Received: from mail-qt1-x836.google.com ([2607:f8b0:4864:20::836]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <watson@cloudflare.com>) id 1hvVRT-0004hY-KR for ietf-http-wg@w3.org; Wed, 07 Aug 2019 23:34:04 +0000
Received: by mail-qt1-x836.google.com with SMTP id n11so90207886qtl.5 for <ietf-http-wg@w3.org>; Wed, 07 Aug 2019 16:33:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=zxHfzZNZfQZ7/TUInUWKpJweKWjvyiV2ME2+sWHiOso=; b=wqSGSd7qn51+HvuUZFaTp/kOL4TMEi3370HQ6rO6beeg9JOxjR0DBSAjoJSPVEU3+0 EQtgZ24UxZrRmk8eWdG7YSYlTIGWFeTOEgxngFJekxSjjHd10kzd44ePGaUb2epZCAI0 Xpjj0RReoJjlrtrP1UmguuYlb070FjK/VzrhI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zxHfzZNZfQZ7/TUInUWKpJweKWjvyiV2ME2+sWHiOso=; b=e1/pIpQwR7+dV70aJtIjDJCRZgeSl1hFaOOoMm0inDyo2NPbDPMnt6lo0pnpTaJghh WGqqziwwJYMy/dUJB+htmkohuX+XiFmS2ouC+VW6YPiHsm44jFVC813qhER56TnjGhE5 /TBhL/FR4UcW98V2hMbT5LzUui4bahSjOIO9c1Ybbqff7E7egy8wk5QQO7/vC5KTw34l lSYSl6TwEYznc1Lp8xCrQfonL5hnaUhJSFKuD3WNfhWwCFCINWiXIPgeq/i1lnza9oNv ntXf2dKFz3XTN1TRUqWvn8KIA7Y4mkb5/I6E9GrKd3GOHLWPAEoHvATHSu8VXBjZJIO7 cBXQ==
X-Gm-Message-State: APjAAAX+FpjIzlC9i5bNW0AOKGqGL+ZipcjT+SlbjK4a04o092csJWAV i7bJnj1INlx7HsPV3Oh3JxIFEq1/+aQaavPY+/sPKKv6AE0=
X-Google-Smtp-Source: APXvYqyo4TByLdLv5Ux6dk6E0s6OLAWVFcdlLvU803wtp5dYurEdiZOC1ROwR2rWyIr8R89idjxnjgpW3vznavf0jh0=
X-Received: by 2002:a0c:c382:: with SMTP id o2mr10650743qvi.75.1565220821834; Wed, 07 Aug 2019 16:33:41 -0700 (PDT)
MIME-Version: 1.0
From: Watson Ladd <watson@cloudflare.com>
Date: Wed, 7 Aug 2019 16:33:31 -0700
Message-ID: <CAN2QdAED_6C7GmyTSXqTaZHFUYm7GVRWa753WbqrJ7Uf8fwp9w@mail.gmail.com>
To: ietf-http-wg@w3.org
Content-Type: multipart/alternative; boundary="00000000000014e861058f8f5f9f"
Received-SPF: pass client-ip=2607:f8b0:4864:20::836; envelope-from=watson@cloudflare.com; helo=mail-qt1-x836.google.com
X-W3C-Hub-Spam-Status: No, score=-0.8
X-W3C-Hub-Spam-Report: AWL=0.823, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_NW=0.5
X-W3C-Scan-Sig: mimas.w3.org 1hvVRT-0004hY-KR 78d28a8c88d43b1558fba30d016750ee
X-caa-id: 5c02faa718
X-Original-To: ietf-http-wg@w3.org
Subject: Comments on draft-ietf-httpbis-http2-secondary-certs-04
Archived-At: <https://www.w3.org/mid/CAN2QdAED_6C7GmyTSXqTaZHFUYm7GVRWa753WbqrJ7Uf8fwp9w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36946
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>

Dear all,

I'm concerned about changing the format of the certificate frame payload
based on the unsolicited flag. Instead I would prefer that we reserve
request id 0 for unsolicited frames. This way there is only one possible
format, versus 2. It's a very minor quibble, but I strongly feel things
should be as simply parseable as possible.

Secondly the draft seems to hold open the possibility of having multiple
certificate fragments being assembled at once. This seems like a misfeature
to me.

Thirdly the CERTIFICATE frame context in the certificate frame starts with
the request-id but is otherwise unconstrained. I'm not entirely sure why
the older approach of having the request specify it was a bad idea, but
perhaps it was a bad idea for reasons I haven't learned yet.

Then it seems both '*' and '_' are treated as wildcards in the Required
Domains extension. It's not clear to me why one or both would be required.

I still am not clear on the joint versus separate authoritative issue (is
it a question of simultaneity)  and why that implies clients MUST NOT
assume colocation in the future. Even if joint authorization existed, it
might change for a future connection.

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.

Section 6.5 seems to imply that the set of certificates can shrink as a
request is being processed. It's a bit surprising to me: I thought there
would only be one transition as the USE_CERTIFICATE frame arrives and is
processed, for any potential CERTIFICATE_REQUIRED relevant to the stream.
The fact that these frames are no longer on the stream but on stream 0
might be fooling me as to the ordering.

The second half of section 6.5 says clients don't know if the ambient
authority of a freely useable certificate will be honored. True, but I
imagine a server would request a certificate explicitly if needed instead
of reject the request assuming it had seen all of them. I would suggest a
SHOULD for servers requesting certificates explicitly when accessing
protected resources. Do people have real usecases/ sufficiently complex
configurations where this won't work?

Sincerely,
Watson Ladd