Re: [auth48] AUTH48: RFC-to-be 9530 <draft-ietf-httpbis-digest-headers-13> for your review

[Lucas Pardue <[e-mail]>]

Hi,

Thank you very much for the review! I don't know if you intended this or
not but I really appreciate the beauty of keeping the last two digits the
same when replacing RFC 3230 with 9530.

I've been working through the diff and have a couple of comments/questions
but first let's reply to each of your points in-line.

On Sat, Dec 2, 2023 at 6:21 AM <[e-mail]> wrote:

> Authors,
>
> While reviewing this document during AUTH48, please resolve (as necessary)
> the following questions, which are also in the XML file.
>
> 1) <!-- [rfced] We have updated the following sentence for readability.
> Please let us know if you prefer otherwise.
>
> Original:
>    It also coined the term "instance" and "instance
>    manipulation" in order to explain concepts that are now more
>    universally defined, and implemented, as HTTP semantics such as
>    selected representation data (Section 8.1 of [HTTP]).
>
> Current:
>    It also coined the terms "instance" and "instance
>    manipulation" in order to explain concepts, such as selected
>    representation data (Section 8.1 of [HTTP]), that are now more
>    universally defined and implemented as HTTP semantics.
> -->
>

Love the new text.


>
>
> 2) <!-- [rfced] May this be rephrased as follows for readability
> and to reduce the usage of "of"?
>
> Original:
>    The term "checksum" describes the output of the application of an
>    algorithm to a sequence of bytes, whereas "digest" is only used in
>    relation to the value contained in the fields.
>
> Perhaps:
>    The term "checksum" describes the output of applying an algorithm
>    to a sequence of bytes, whereas "digest" is only used in relation
>    to the value contained in the fields.
> -->
>

Works for me.


>
>
> 3) <!-- [rfced] May we format these terms as follows to be similar to how
> the terms appear earlier within Section 1.4?
>
> Original:
>    Integrity fields: collective term for Content-Digest and Repr-Digest
>
>    Integrity preference fields: collective term for Want-Repr-Digest and
>    Want-Content-Digest
>
> Perhaps:
>    "Integrity fields" is the collective term for Content-Digest and
>    Repr-Digest.
>
>    "Integrity preference fields" is the collective term for
> Want-Repr-Digest
>    and Want-Content-Digest. -->
>

Works for me.


>
>
> 4) <!--[rfced] May we move this note outside of the sourcecode
> elements? Also, may we update to one note that applies to all the
> wrapped lines (as follows), or do you prefer to keep the 18 instances
> of the note?
>
> Current (18 instances):
>    NOTE: '\' line wrapping per RFC 8792
>
> Suggested:
>    NOTE: Throughout this document, '\' line wrapping is per [RFC8792].
> -->
>
> My understanding of
https://datatracker.ietf.org/doc/html/rfc8792#section-7 is that the format
in the current document is required. We have automated tooling that relies
on the prescence of the 36-character string at the top in order to run the
wrap/unwrap procedures. My preference is to keep all occurences as they are
already stated. Note that the HTTP Message Signatures
<https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/>
draft also has the same usage and requirements, so we should make sure they
align.

>
> 5) <!--[rfced] For clarity, may the final phrase be moved as follows?
>
> Original:
>    Want-Content-Digest indicates that the sender would like to receive a
>    content digest on messages associated with the request URI and
>    representation metadata, using the Content-Digest field.
>
>    Want-Repr-Digest indicates that the sender would like to receive a
>    representation digest on messages associated with the request URI and
>    representation metadata, using the Repr-Digest field.
>
> Perhaps:
>    Want-Content-Digest indicates that the sender would like to receive
>    (via the Content-Digest field) a content digest on messages
>    associated with the request URI and representation metadata.
>
>    Want-Repr-Digest indicates that the sender would like to receive
>    (via the Repr-Digest field) a representation digest on messages
>    associated with the request URI and representation metadata.
> -->
>

Much nicer, love it.


>
>
> 6) <!-- [rfced] May this be rephrased as follows to improve readability?
>
> Original:
>    For adversarial situations,
>    selecting which of the "Active" algorithms are acceptable will depend
>    on the level of protection the circumstances demand.
>
> Perhaps:
>    For adversarial situations, selection of the acceptable "Active"
>    algorithms will depend on the level of protection the circumstances
>    demand. -->
>

Love it.


>
> 7) <!-- [rfced] Please clarify; is the intended meaning
> "help some applications avoid undue operational overhead"?
> If so, we suggest rephrasing as follows.
>
> Original:
>    Permitting the use of these algorithms can help some
>    applications, for example, those that previously used [RFC3230], are
>    migrating to this specification (Appendix E), and have existing
>    stored collections of computed digest values avoid undue operational
>    overhead caused by recomputation using other more-secure algorithms.
>
> Option A:
>    Permitting the use of these algorithms can help some
>    applications (such as those that previously used [RFC3230], are
>    migrating to this specification (Appendix E), and have existing
>    stored collections of computed digest values) avoid undue
>    operational overhead caused by recomputation using other more-secure
>    algorithms.
>
> Option B:
>    Permitting the use of these algorithms can help some
>    applications -- specifically those applications that previously used
>    [RFC3230], are migrating to this specification (Appendix E), and have
>    existing stored collections of computed digest values -- avoid undue
>    operational overhead caused by recomputation using other more-secure
>    algorithms.
> -->
>

Good observation. I think option A is the better.


>
> 8) <!-- [rfced] Please clarify "can remove or recalculate and substitute".
> If substitution can happen after either removal or recalculation,
> we suggest adding 'then' as follows.
>
> Original:
>    In the absence of additional
>    security mechanisms, an on-path, malicious actor can remove or
>    recalculate and substitute a digest value.
>
> Perhaps:
>    In the absence of additional
>    security mechanisms, an on-path, malicious actor can remove or
>    recalculate and then substitute a digest value. -->
>

The intent here is "actor can either A or B", specifically they can either
remove entirely (A) or recalculate & substitute (B). Remove & substitute
(with some bogus value) isn't a valid threat because of the design. Would
phrase this as the following make things clearer?

Perhaps:
   In the absence of additional
   security mechanisms, an on-path, malicious actor can either remove or
   a digest value entirely, or substitute it with a new digest value
computed over
   manipulated representation data or content.


>
> 9) <!--[rfced] May this be rephrased for conciseness, or is the word
> "manipulation" needed?
>
> Original:
>    In the scenario where there is no content to send, the digest of an
> empty
>    string can be included in the message and, if signed, can help the
>    recipient detect if content was added either as a result of accident
>    or purposeful manipulation.
>
> Perhaps:
>    In the scenario where there is no content to send, the digest of an
> empty
>    string can be included in the message and, if signed, can help the
>    recipient detect if content was added accidentally or purposely.
> -->
>

I'd like to keep manipulation here.


>
>
> 10) <!-- [rfced] References
>
> a) For [UNIX], would you like the title and publication date to be
> updated to match how it appears in this file:
> <https://unix.org/version2/u98paper.pdf>?  Or do you prefer to
> leave the reference as is, similar to how it appears in RFC 3230?
>
> Original:
> [UNIX]     The Open Group, "The Single UNIX Specification, Version 2
>            - 6 Vol Set for UNIX 98", February 1997.
>
> Perhaps:
> [UNIX]     The Open Group, "The Single UNIX® Specification, Version 2
>            and UNIX 98", January 1998.
>

I have no preference, so I'd take yours. Let us know.


>
> b) The following reference has a Warning Notice stating that the
> publication has been "withdrawn (archived)". Please let us know if
> any updates are needed.
>
> Original:
> [NIST800-32]
>            National Institute of Standards and Technology, U.S.
>            Department of Commerce, "Introduction to Public Key
>            Technology and the Federal PKI Infrastructure", February
>            2001, <https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
>            nistspecialpublication800-32.pdf>.
>

I'm not 100% sure what to do here. I asked some folks with better knowledge
of crypto if they can recommend a better citation.


> c) RFC 7807 has been obsoleted by RFC 9457. May we replace
> RFC 7807 with RFC 9457 in this document?
> -->
>

Yep!


>
> 11) <!-- [rfced] Please clarify "the first 10" here.
>
> Original:
>    The server satisfies the client request by responding with a partial
>    representation (equivalent to the first 10 of the JSON object
>    displayed in whole in Figure 2).
>
> Perhaps:
>    The server satisfies the client request by responding with a partial
>    representation (equivalent to the first 10 bytes of the JSON object
>    displayed in whole in Figure 2). -->
>

Your suggestion is correct, lets do it.


>
>
> 12) <!-- [rfced] May "bytes CRLF" be updated to "CRLF bytes"?
>
> Original:
> In the response content below, the string "\r\n" represent the bytes CRLF.
>
> Perhaps:
> In the response content below, the string "\r\n" represents the CRLF bytes.
> -->
>

Works for me.


>
>
> 13) <!-- [rfced] For the list of digest values in Appendix D, would you
> prefer
> to format it as a definition list rather than a sourcecode element?
> If you do, placing the line break would not be necessary.
> -->
>

I'd like to keep the existing format due to the wrapping angle discussed
up-thread.


>
> 14) <!-- [rfced] Please review the "Inclusive Language" portion of the
> online
> Style Guide <
> https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> and let us know if any changes are needed. Note that our script did not
> flag
> any words in particular, but this should still be reviewed as a best
> practice. -->
>

Reviewed and no changes are needed.


>
> 15) <!-- [rfced] FYI - We have added expansions for abbreviations upon
> first use
> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
> expansion in the document carefully to ensure correctness. -->
>

Reviewed and all correct.

>
>
> 16) <!-- [rfced] Terminology
>
> a) The following term appears inconsistently in this document. If there
> are no objections, we will update to the form on the right.
>
>   Range Request(s) vs. range request(s)
>

No objection!


>
>
> b) Regarding "gzip" vs. "GZIP", both forms are used in this document;
> may all caps be used when it appears outside a header field?
> Specifically, may we update (4 instances) to all caps as follows?
>
>    the same data with a GZIP coding ...
>    Figure 2: Request Containing a GZIP-Encoded JSON Object
>    Sending the GZIP-coded data without ...
>    Figure 6: Partial Response from a GZIP-Encoded Representation
>

Yep, this is good.


>
>
> c) This term appears as Content-Encoding (with hyphen) for the header
> field. Should the title of Section 6.5 be updated?
>
> Current: 6.5.  Variations within Content Encoding
> Perhaps: 6.5.  Variations within Content-Encoding
>

Works for me.


> ("Merkle Integrity Content Encoding" will remain as is because
> it matches the title of the referenced Internet-Draft.)
>
>
> d) Do the following terms mean the same thing? If so, would you like
> to choose one form to use throughout the document for consistency?
>
>   Repr-Digest field vs. Repr-Digest HTTP field
>

The convention appears to be a use the HTTP suffix in the declaration of
the field. So I'd like to keep the current text but make the following
change

Current:
  Senders can indicate their interest in Integrity fields and hashing
algorithm preferences using the Want-Content-Digest or Want-Repr-Digest
fields.

Proposed:
  Senders can indicate their interest in Integrity fields and hashing
algorithm preferences using the Want-Content-Digest or Want-Repr-Digest
HTTP fields.

  hash algorithm vs. hashing algorithm
>

These terms are related but are used slightly differently. Lets keep the
usage as is.


>
> e) The following terms use <tt> tags inconsistently throughout the
> document. Please review the usage of <tt> and let us know if any
> updates are needed.
>
> Byte Sequence
>
Remove <tt> for all these

Content-Digest
>
Apply <tt> for all these

Dictionary
>
Remove <tt> for all these

Digest (field)
>
Apply <tt> for all these


> PATCH (when referring to PATCH requests)
>
Remove <tt> for all these


> Repr-Digest
>
Apply <tt> for all these


> Want-Digest
>
Apply <tt> for all these

Want-Repr-Digest
>
Apply <tt> for all these


> -->
>

Additional observations from reviewing the XML doc

LP 1) Section 1.4 changed from CRLF (CR LF), to CRLF. Please revert this in
order to maintain consistency with RFC 9110.

LP 2) Section 2 and 3 has changes of the form:

Original:
   A sender MAY send a digest without knowing whether the recipient
   supports a given hashing algorithm, or even knowing that the recipient
will ignore
   it.

RFC Editor:
   A sender MAY send a digest without knowing whether the recipient
   supports a given hashing algorithm or if the recipient will ignore
   it.

Unfortunately, this breaks the intention of the statement. The key point is
that the sender can send a digest that it knows the recipient doesn't want.
That's a bit counter-intuituive but it is allowed by the design and we want
to call it out. I can see how the original text might be marginally
unclear. I'm open to ideas to clarify it.  Here's my proposal which breaks
the compound statement into two:

Proposed:
   A sender MAY send a digest without knowing whether the recipient
   supports a given hashing algorithm. A sender MAY send a digest if it
knows the
   recipient will ignore it.

LP 3) Section 6.3 gnarly digests'

Original:
  Any mangling of Integrity fields, including digests' de-duplication
  or combining different field values (see Section 5.2 of [HTTP])
  might affect signature validation.

RFC Editor:
  Any mangling of Integrity fields, including the digests' de-duplication
  or combination of different field values (see Section 5.2 of [HTTP])
  might affect signature validation.

Both of these forms are pretty gnarly and I still find hard to read (the
clarity from stepping away from the text for 6 months :-) ) WDYT to this
instead?

Proposed:
  Any mangling of Integrity fields might affect signature validation. For
example, de-duplicating digests or combining different field values (see
Section 5.2 of [HTTP]).


Once again thanks for the review and consideration.

Cheers,
Lucas


>
> Thank you.
>
> RFC Editor/mc/ar
>
>
> On Dec 1, 2023, [e-mail] wrote:
>
> *****IMPORTANT*****
>
> Updated 2023/12/01
>
> RFC Author(s):
> --------------
>
> Instructions for Completing AUTH48
>
> Your document has now entered AUTH48.  Once it has been reviewed and
> approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>
> You and you coauthors are responsible for engaging other parties
> (e.g., Contributors or Working Group) as necessary before providing
> your approval.
>
> Planning your review
> ---------------------
>
> Please review the following aspects of your document:
>
> *  RFC Editor questions
>
>   Please review and resolve any questions raised by the RFC Editor
>   that have been included in the XML file as comments marked as
>   follows:
>
>   <!-- [rfced] ... -->
>
>   These questions will also be sent in a subsequent email.
>
> *  Changes submitted by coauthors
>
>   Please ensure that you review any changes submitted by your
>   coauthors.  We assume that if you do not speak up that you
>   agree to changes submitted by your coauthors.
>
> *  Content
>
>   Please review the full content of the document, as this cannot
>   change once the RFC is published.  Please pay particular attention to:
>   - IANA considerations updates (if applicable)
>   - contact information
>   - references
>
> *  Copyright notices and legends
>
>   Please review the copyright notice and legends as defined in
>   RFC 5378 and the Trust Legal Provisions
>   (TLP – https://trustee.ietf.org/license-info/).
>
> *  Semantic markup
>
>   Please review the markup in the XML file to ensure that elements of
>   content are correctly tagged.  For example, ensure that <sourcecode>
>   and <artwork> are set correctly.  See details at
>   <https://authors.ietf.org/rfcxml-vocabulary>.
>
> *  Formatted output
>
>   Please review the PDF, HTML, and TXT files to ensure that the
>   formatted output, as generated from the markup in the XML file, is
>   reasonable.  Please note that the TXT will have formatting
>   limitations compared to the PDF and HTML.
>
>
> Submitting changes
> ------------------
>
> To submit changes, please reply to this email using ‘REPLY ALL’ as all
> the parties CCed on this message need to see your changes. The parties
> include:
>
>   *  your coauthors
>
>   *  [e-mail] (the RPC team)
>
>   *  other document participants, depending on the stream (e.g.,
>      IETF Stream participants are your working group chairs, the
>      responsible ADs, and the document shepherd).
>
>   *  [e-mail], which is a new archival mailing list
>      to preserve AUTH48 conversations; it is not an active discussion
>      list:
>
>     *  More info:
>
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>
>     *  The archive itself:
>        https://mailarchive.ietf.org/arch/browse/auth48archive/
>
>     *  Note: If only absolutely necessary, you may temporarily opt out
>        of the archiving of messages (e.g., to discuss a sensitive matter).
>        If needed, please add a note at the top of the message that you
>        have dropped the address. When the discussion is concluded,
>        [e-mail] will be re-added to the CC list and
>        its addition will be noted at the top of the message.
>
> You may submit your changes in one of two ways:
>
> An update to the provided XML file
> — OR —
> An explicit list of changes in this format
>
> Section # (or indicate Global)
>
> OLD:
> old text
>
> NEW:
> new text
>
> You do not need to reply with both an updated XML file and an explicit
> list of changes, as either form is sufficient.
>
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text,
> and technical changes.  Information about stream managers can be found in
> the FAQ.  Editorial changes do not require approval from a stream manager.
>
>
> Approving for publication
> --------------------------
>
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
>
>
> Files
> -----
>
> The files are available here:
>   https://www.rfc-editor.org/authors/rfc9530.xml
>   https://www.rfc-editor.org/authors/rfc9530.html
>   https://www.rfc-editor.org/authors/rfc9530.pdf
>   https://www.rfc-editor.org/authors/rfc9530.txt
>
> Diff file of the text:
>   https://www.rfc-editor.org/authors/rfc9530-diff.html
>   https://www.rfc-editor.org/authors/rfc9530-rfcdiff.html (side by side)
>
> Diff of the XML:
>   https://www.rfc-editor.org/authors/rfc9530-xmldiff1.html
>
>
> Tracking progress
> -----------------
>
> The details of the AUTH48 status of your document are here:
>   https://www.rfc-editor.org/auth48/rfc9530
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
> --------------------------------------
> RFC9530 (draft-ietf-httpbis-digest-headers-13)
>
> Title            : Digest Fields
> Author(s)        : R. Polli, L. Pardue
> WG Chair(s)      : Mark Nottingham, Tommy Pauly
> Area Director(s) : Murray Kucherawy, Francesca Palombini
>