Genart last call review of draft-ietf-httpbis-client-cert-field-04

Peter Yee via Datatracker <noreply@ietf.org> Fri, 24 February 2023 13:41 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 82C05C169535 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 24 Feb 2023 05:41:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.948
X-Spam-Level:
X-Spam-Status: No, score=-4.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btlDNNn-yjHY for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 24 Feb 2023 05:41:10 -0800 (PST)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2AB7C1595FD for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 24 Feb 2023 05:40:50 -0800 (PST)
Received: from lists by lyra.w3.org with local (Exim 4.94.2) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1pVYJN-00AHTw-2h for ietf-http-wg-dist@listhub.w3.org; Fri, 24 Feb 2023 13:40:33 +0000
Resent-Date: Fri, 24 Feb 2023 13:40:33 +0000
Resent-Message-Id: <E1pVYJN-00AHTw-2h@lyra.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by lyra.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <noreply@ietf.org>) id 1pVYJL-00AHSy-3E for ietf-http-wg@listhub.w3.org; Fri, 24 Feb 2023 13:40:31 +0000
Received: from mail.ietf.org ([50.223.129.194]) by mimas.w3.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <noreply@ietf.org>) id 1pVYJK-00CtKk-4c for ietf-http-wg@w3.org; Fri, 24 Feb 2023 13:40:31 +0000
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E50C159A1D; Fri, 24 Feb 2023 05:40:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Peter Yee via Datatracker <noreply@ietf.org>
To: gen-art@ietf.org
Cc: draft-ietf-httpbis-client-cert-field.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.11.0
Auto-Submitted: auto-generated
Message-ID: <167724601881.59677.12957566760779128172@ietfa.amsl.com>
Reply-To: Peter Yee <peter@akayla.com>
Date: Fri, 24 Feb 2023 05:40:18 -0800
Received-SPF: pass client-ip=50.223.129.194; envelope-from=noreply@ietf.org; helo=mail.ietf.org
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 1pVYJK-00CtKk-4c 070abcf52251a6a34db1d05ea23439ac
X-Original-To: ietf-http-wg@w3.org
Subject: Genart last call review of draft-ietf-httpbis-client-cert-field-04
Archived-At: <https://www.w3.org/mid/167724601881.59677.12957566760779128172@ietfa.amsl.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/50742
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>

Reviewer: Peter Yee
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-httpbis-client-cert-field-04
Reviewer: Peter Yee
Review Date: 2023-02-24
IETF LC End Date: 2023-02-23
IESG Telechat date: Not scheduled for a telechat

Summary: This draft documents a standardized means of conveying a client
certificate and chain between a TLS-terminating reverse proxy (TTRP) and an
origin server so as to allow the origin server to make decisions based on the
identity of the client. This draft is fairly straightforward and not difficult
to follow, but there are a couple of issues that could use clarification.
[Ready with issues.]

Major issues: None

Minor issues:

The text defining the header fields for Client-Cert and Client-Cert-Chain in
section 2 along with the example in Appendix A should make clear:

1) The client certificate placed in Client-Cert is not included in the optional
Client-Cert-Chain. 2) Client-Cert-Chain should only appear when Client-Cert is
also present. 3) That the root certificate of the chain should be added to the
Client-Cert-Chain by the TTRP.

Confusion might arise because the header definitions make no mention of this,
but the example in Appendix A shows a certificate chain (Figure 1) that is
inclusive of a client certificate, but Figure 3 shows that the client
certificate is not included in the chain. The text in Appendix A says the
client only presents the client and intermediate certificate, so point #3 above
is needed.

In section 2.4, second paragraph, second sentence: this seems really expensive
to add the client cert and possibly the certificate chain to every request the
client sends to the TTRP. The sending of those fields to the could outweigh the
size of the request by quite a bit. Would it be possible to substitute
something smaller on subsequent requests between the TTRP and the origin server
since they already require a trusted connection between them? A hash of the
field(s) value(s)? Something else that helps combat the potential overhead? I
realize that I'm asking about a non-trivial change to the draft, which is easy
for me to do and difficult for the authors to implement. ;-)

Nits/editorial comments:

General:

Change all occurrences of “mutually-authenticated” to “mutually authenticated”.

Specific:

Page 6, section 2.4, 2nd paragraph, 2nd sentence: change the “are” to “is”.

Page 8, section 3.2, 3rd sentence: append a comma after “e.g.”.

Page 8, section 4, 1st paragraph, 1st sentence: change “server side” to
“server-side”.

Page 8, section 4, 2nd paragraph, 2nd sentence: append a comma after “fields”.

Page 9, 3rd paragraph, 5th sentence: append a comma after “Alternatively”.

Page 15, section B.1, 3rd sentence: change the semicolon after “possible” to a
comma.

Page 15, section B.3, 1st sentence: delete one period after “etc”.

Page 16, 1st partial paragraph: append a comma after “full”.