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

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?

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?

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.

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?

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"

-------------------------------------------------------------------------------
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.

Received on Tuesday, 17 September 2024 18:18:24 UTC