[Gen-art] Re: Genart last call review of draft-ietf-httpbis-unprompted-auth-10
David Schinazi <dschinazi.ietf@gmail.com> Tue, 10 September 2024 03:07 UTC
Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03049C14CE39; Mon, 9 Sep 2024 20:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 nQrHJ1OIE__6; Mon, 9 Sep 2024 20:07:33 -0700 (PDT)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE59C1D6200; Mon, 9 Sep 2024 20:07:33 -0700 (PDT)
Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a8d2b24b7a8so442338866b.1; Mon, 09 Sep 2024 20:07:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725937651; x=1726542451; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=/SULlhtiM2lDeHY11VHJZqsn04C5DFpDL8iOcI3ZvPA=; b=SFiIFRSxRFYSdkdGHyfzHk39UvZciyy+U3Qb2AHB0K5sQ4ipK2oTd2W9jF/N5JG4Ja LE8qjVL4bagkFIZBsHndu64NHpaT/YCSv14Z541UHtBMFBj4VA4l/vryGXw95FAR5U6W L8GQtGhgkxNHj07xuLkxnHF2NdwiaK/lNyIKQaj8I5pj9eC36oZIRE5zegde+v5e1RbZ EsWx628LJbaQpgzI66G78ftADIc2VLUXqWfQ2wlPvlpA6a1aDmg6la9eASgBOvi14eeD Mg8TZc16eghGNX5MBJk+IBWimsOOaUZSVAzqgLExuT61sW0X5z6unV+1QEMYLw3Yy9ab I1Yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725937651; x=1726542451; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=/SULlhtiM2lDeHY11VHJZqsn04C5DFpDL8iOcI3ZvPA=; b=aqiKHgeqvs/Buk/0OOfmY677xrkDCAXoUdEtODD/t63tbCoJdsl7f7jBghhwQZENdh 8Pl9fI2hX62ncCb663hk9tcH9J4aItiLBuzW5P8syBTf3itcULRLctH+5HvIFikNm4vC UPBJq1H5lXSh0xfMvM3WlEC4/oOJSRvry9cl44T85XUyF3IPpsJZ7UwWMuHSAMH3GEyZ CrQKZRfWpfyE0sS+vcQ/aDN6DoFH2KrSMHBM7aSyJpRVb0k+BmCGJfg71xb0yMP+l5no 1XoERUd1v6ScbXzltqEcPVrlmuP5RrIcEkV5lk+v//ftUAJx989lDcxt6obSiql5pGKK oBsQ==
X-Forwarded-Encrypted: i=1; AJvYcCUoXeiuxlvWmdDP5szRpaF2P8SPKtC/tAQZhfN6Xge0Rp75L55dQ/JX2VNRw/LK/ILrvYslXOIthjHc@ietf.org, AJvYcCVvpEX3TVdcYbzswojhp8HRdtEd4JHXmUvV3mvVxLPiMB8YVXiKpUhWwYz7B734KBNFMDVp3ARdlmxy2JSNBo27aU1rMikLuIELbZ8M0CkarcG63vFghA==@ietf.org
X-Gm-Message-State: AOJu0YxmZyqx+0sJu7ctLbuCY9nNJhlnLw9yqaElXdJmfrzIHBMpskHx q/JfqkKVFoSzyLWn5yYidpEvKwwyXdmd2hiGWRr9s3vl3ltPOWH7U6QacDXVyIHkh84E6d1kuuR /FScLh1eRbAYrHmwVhKBV/gg2kWM=
X-Google-Smtp-Source: AGHT+IH7u01cWd0kWe3oqNNZwhpu8huNzZshOEZhyc7CJB40B6Im3VEL3xQn3NvpvfsdvTaSgqfLXHfucvSvoJWPJHM=
X-Received: by 2002:a17:907:60cb:b0:a8d:592d:f56 with SMTP id a640c23a62f3a-a8d7320dc77mr144681866b.31.1725937650240; Mon, 09 Sep 2024 20:07:30 -0700 (PDT)
MIME-Version: 1.0
References: <172592463661.2713180.15649778041521386900@dt-datatracker-68b7b78cf9-q8rsp>
In-Reply-To: <172592463661.2713180.15649778041521386900@dt-datatracker-68b7b78cf9-q8rsp>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Mon, 09 Sep 2024 20:07:18 -0700
Message-ID: <CAPDSy+40iGOkURV4HOxZnb+2oe00Ns0ieSyXg=x-==PZ3K205g@mail.gmail.com>
To: Reese Enghardt <ietf@tenghardt.net>
Content-Type: multipart/alternative; boundary="0000000000008c12a10621bb2ca0"
Message-ID-Hash: DOXL7CCQE6JJWGIKQDYW5AYPQQDAFCDV
X-Message-ID-Hash: DOXL7CCQE6JJWGIKQDYW5AYPQQDAFCDV
X-MailFrom: dschinazi.ietf@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-gen-art.ietf.org-0; header-match-gen-art.ietf.org-1; header-match-gen-art.ietf.org-2; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: gen-art@ietf.org, draft-ietf-httpbis-unprompted-auth.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Gen-art] Re: Genart last call review of draft-ietf-httpbis-unprompted-auth-10
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/vL3nQmXTEnrUgGdzSn2gi6rNGb0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Owner: <mailto:gen-art-owner@ietf.org>
List-Post: <mailto:gen-art@ietf.org>
List-Subscribe: <mailto:gen-art-join@ietf.org>
List-Unsubscribe: <mailto:gen-art-leave@ietf.org>
Hi Reese, and thanks for your review! I've landed this commit based on your comments: https://github.com/httpwg/http-extensions/commit/6cf4a202c6034888123383d10239e13d639d71d4 I'll submit a new draft revision incorporating it once IETF LC is done. More detailed responses inline. David On Mon, Sep 9, 2024 at 4:30 PM Reese Enghardt via Datatracker < noreply@ietf.org> wrote: > Reviewer: Reese Enghardt > Review result: Ready with Nits > > 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://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > Document: draft-ietf-httpbis-unprompted-auth-10 > Reviewer: Reese Enghardt > Review Date: 2024-09-09 > IETF LC End Date: 2024-09-11 > IESG Telechat date: Not scheduled for a telechat > > Summary: The document is fairly clear and concise. I have a few > suggestions to > make the document more accessible. > > Major issues: None. > > Minor issues: > > Section 1: > > "Members of less well-defined communities might use more ephemeral keys to > acquire access to geography- or capability-specific resources, as issued > by an > entity whose user base is larger than the available resources can support > (by > having that entity metering the availability of keys temporally or > geographically)." > > Does this sentence introduce a new use case that is separate from the > company > use case described in the previous sentence, or is it a similar use case > but > under different circumstances? It is not quite clear to me what a "member > of a > less well-defined community" is, I assume "less well-defined than > employees of > a company"? Are users within a certain geography or with devices with > specific > capabilities an example? What does "larger than the available resources can > support" mean here, is this part tied to the new use case or circumstances > described before? Please consider rephrasing this sentence to make it > clearer. > Good point. The intent was for this to be a separate example. I've rephrased by adding "As another example, " to clarify this. Section 2: > > As a non-expert, I would appreciate a high-level description of the entire > flow > here. The client generates the data to be signed and then sends the > signature, > and the details are in Sections 3 and 4, but what happens afterwards? > Please > consider adding one or two sentences to explain the basic principle of how > the > scheme works, i.e., how the server is then able to authenticate the client. > Agreed. Added <<Once the server receives these, it can check whether the signature validates against an entry in its database of known keys. The server can then use the validation result to influence its response to the client, for example by restricting access to certain resources.>> Section 5: > > As this section is titled "Example", I expected a full example of the > scheme, > but it looks like this is just an example of a request. Please consider > turning > this section into a full example of how the scheme works, potentially > moving it > to after Section 6. > The response isn't particularly interesting here, since there's no header being sent back by this mechanism. This is an example of the main on-the-wire portion of this spec. I thought through explaining how the server reacts to it, but it ended up being redundant with other portions of text. Nits/editorial comments: None. >
- [Gen-art] Re: Genart last call review of draft-ie… David Schinazi
- [Gen-art] Genart last call review of draft-ietf-h… Reese Enghardt via Datatracker