Re: Mahesh Jethanandani's No Objection on draft-ietf-httpbis-unprompted-auth-11: (with COMMENT)

Hi Mahesh, and thanks for your review.
I've landed this commit in response to your comments:
https://github.com/httpwg/http-extensions/commit/80451f47d1a1bf724bd45bcb531a4a723cff903c
More detailed response inline.
David

On Tue, Sep 17, 2024 at 11:18 AM Mahesh Jethanandani via Datatracker <
noreply@ietf.org> wrote:

> Mahesh Jethanandani has entered the following ballot position for
> draft-ietf-httpbis-unprompted-auth-11: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-unprompted-auth/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> "Abstract", paragraph 2
> > About This Document
>
> I note the fact that the Shepherd writeup was written more than 2 years
> ago.
> Does it need a refresh? For example, two implementations were noted then.
> Has
> that figure changed?
>

The shepherd writeup was written on 2024-08-27, which is visible from the
datatracker metadata. The date you saw is the date that the shepherd writeup
template was written. Maybe the IESG should clarify that in the template.

It also notes that the document has had no specific directorate reviews,
> although I do note that a SECDIR, ARTART, OPSDIR, and GENART review have
> been
> done. What about HTTPDIR?
>

Documents in the HTTPBIS WG are already reviewed by HTTP experts during
development and WGLC, so they don't need HTTPDIR review on top of that.

Section 3, paragraph 5
> >    Note that TLS 1.3 keying material exporters are defined in
> >    Section 7.5 of [TLS], while TLS 1.2 keying material exporters are
> >    defined in [KEY-EXPORT].
>
> I agree with Gunter's review COMMENT that the use of references such as
> [TLS]
> or [KEY-EXPORT] rather than using the RFC number is unusual, even as the
> authors contend that is the style in HTTPBIS WG. Most of the boiler text
> in the
> document continues to use RFC numbers, and I note at least one use of RFC
> number [RFC7627] in the draft.
>

Your comment is noted, but we chose consistency with other HTTP documents.
We intentionally kept 7627 as a number because we didn't want to mention
the non-inclusive term "master" more than we had to.

Section 6.4, paragraph 1
> >    The authentication checks described above can take time to compute,
> >    and an attacker could detect use of this mechanism if that time is
> >    observable by comparing the timing of a request for a known non-
> >    existent resource to the timing of a request for a potentially
> >    authenticated resource.  Servers can mitigate this observability by
> >    slightly delaying responses to some non-existent resources such that
> >    the timing of the authentication verification is not observable.
> >    This delay needs to be carefully considered to avoid having the delay
> >    itself leak the fact that this origin uses this mechanism at all.
>
> Maybe I do not understand this paragraph. The document says that for
> non-existent resource, the response time would be different because it
> does not
> perform an authentication check?? What if it did? In other words,
> regardless of
> whether the resource existed or did not exist, an authentication check is
> always performed. Would a client then be able to detect the difference?
>

That's not how HTTP servers generally work. It's often the case that there
are
non-authenticated pages (e.g. the main landing page), that are separate than
authenticated pages. The way most HTTP servers are implemented is that
it firsts check to see if there is a resource, and if there is one it
checks whether
that resource requires authentication or not.

Found terminology that should be reviewed for inclusivity; see
> https://www.rfc-editor.org/part2/#inclusive_language for background and
> more
> guidance:
>
>  * Term "master"; alternatives might be "active", "central", "initiator",
>    "leader", "main", "orchestrator", "parent", "primary", "server"
>

"Extended Master Secret" is the name of a pre-existing TLS extension.

-------------------------------------------------------------------------------
> NIT
>
> -------------------------------------------------------------------------------
>
> All comments below are about very minor potential issues that you may
> choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool), so
> there
> will likely be some false positives. There is no need to let me know what
> you
> did with these suggestions.
>
> Uncited references: [RFC8792]. Probably because the text in the document
> says
> RFC 8792 (with a space).
>
> Document references draft-schinazi-masque-00, but -04 is the latest
> available
> revision.
>
> Section 2, paragraph 2
> > le TLS 1.2 keying material exporters are defined in [KEY-EXPORT]. I
> agree wit
> >                                  ^^^^^^^^^^^
> You have used the passive voice repeatedly in nearby sentences. To make
> your
> writing clearer and easier to read, consider using active voice.
>
> Section 3.1, paragraph 11
> > ey exporter context (see above) and the a Parameter (see Section 4.2)
> carry t
> >                                     ^^^^^
> Two determiners in a row. Choose either "the" or "a".
>
> Section 3.3, paragraph 5
> >  MUST NOT include any characters other then ASCII letters, digits, dash
> and
> >                                  ^^^^^^^^^^
> Did you mean "other than"?
>
> Section 4, paragraph 1
> >  known keys, see Section 6.3. 4.2. The a Parameter The REQUIRED "a"
> (public
> >                                    ^^^^^
> Two determiners in a row. Choose either "The" or "a".
>
> Section 6.3, paragraph 4
> >  delay needs to be carefully considered to avoid having the delay itself
> leak
> >                              ^^^^^^^^^^^^^^^^^^^
> The verb "considered" is used with the gerund form.
>
>
>
>