Skip to content

nits and minor edits from Med's IESG review #3406

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
boucadair wants to merge 1 commit into
base: main
Choose a base branch
from
Open

nits and minor edits from Med's IESG review #3406

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 11 additions & 11 deletions draft-ietf-httpbis-unencoded-digest.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,7 +48,7 @@ unambiguous exchange of integrity digests of unencoded representation. The
Unencoded-Digest and Want-Unencoded-Digest fields complement existing integrity
fields for this purpose.

This document updates the terms "Integrity fields" and "Integrity preference
This document updates the definitions of terms "Integrity fields" and "Integrity preference
fields" defined in RFC 9530.


Expand Down Expand Up @@ -77,32 +77,32 @@ via the use of additional libraries it would create work in JavaScript that
could contend with other activities. Even on the server side, the re-encoding of
received data might not be acceptable; some coding algorithms are optimized
towards efficient decoding at the cost of complex encoding. A Content-Encoding
field value that indicates a series of encodings adds further complexity.
field value that indicates series of encodings adds further complexity.

A more complex example involves HTTP Range Requests ({{Section 14 of
HTTP}}), where a client issues multiple requests to obtain partial representations
and "stitches" them back into a whole. Unfortunately, if the responses have
different content codings, the `Repr-Digest` field will vary by the
server's selected encoding (i.e. the Content-Encoding header field, {{Section
server's selected encoding (i.e., the Content-Encoding header field, {{Section
8.4 of HTTP}}). This provides a challenge for a client - in order to verify the
integrity of the pieced-together whole it would need to remove the encoding of
each part, combine them, and then encode the result in order to compare against
one or more `Repr-Digest`s.

The Accept-Encoding header field ({{Section 12.5.3 of HTTP}}) provides the means
to indicate preferences for content codings. It is possible for an endpoint to
indicate a preference for no encoding, for example by sending the "identity"
indicate a preference for no encoding, for example, by sending the "identity"
token. However, codings often provide data compression that is advantageous.
Disabling content coding in order to simplify integrity checking is possibly an
unacceptable trade-off.
Disabling content coding in order to simplify integrity checking might not be
an acceptable trade-off.

For a variety of reasons, decoding and re-encoding content in order to benefit
from HTTP integrity fields is not preferable. This specification defines the
Unencoded-Digest and Want-Unencoded-Digest fields to support a simpler validation
workflow in some scenarios where content coding is applied. These fields
complement the other integrity fields defined in {{DIGEST-FIELDS}}.

This document updates the term "Integrity fields" defined in {{DIGEST-FIELDS}}
This document updates the definition of term "Integrity fields" defined in {{DIGEST-FIELDS}}
to also include the Unencoded-Digest field, and the term "Integrity preference
fields" defined in {{DIGEST-FIELDS}} to also include the Want-Unencoded-Digest
field.
Expand All @@ -112,7 +112,7 @@ field.
{::boilerplate bcp14-tagged}

This document uses the Augmented BNF defined in {{!RFC5234}} and updated by
{{!RFC7405}}. This includes the rules: LF (line feed)
{{!RFC7405}}. This includes the rules: LF (line feed).

This document uses the following terminology from {{Section 3 of
!STRUCTURED-FIELDS=RFC9651}} to specify syntax and parsing: Byte Sequence,
Expand Down Expand Up @@ -225,7 +225,7 @@ preferences are an application-specific concern.
STRUCTURED-FIELDS}}). This specification does not define any Parameters;
future extensions may do so. Unknown Parameters MUST be ignored.

Examples:
Examples of valid Want-Unencoded-Digest values are:

~~~ http-message
Want-Unencoded-Digest: sha-256=1
Expand Down Expand Up @@ -346,7 +346,7 @@ opportunity for an attacker to direct malicious data into a decoder. One
possible mitigation would be to also provide a Content-Digest or Repr-Digest in
the message, allowing for validation of the received bytes before further
processing. An attacker that can substitute various parts of an HTTP message
presents several risks; {{Sections 6.1, 6.2 and 6.3 of DIGEST-FIELDS}}
presents several risks; {{Sections 6.1, 6.2, and 6.3 of DIGEST-FIELDS}}
describe relevant considerations and mitigations.

A content coding may provide encryption capabilities, for example "aes128gcm"
Expand All @@ -362,7 +362,7 @@ coding is used, the security considerations in {{Section 4 of ?RFC8188}} apply.
# IANA Considerations

IANA is asked to update the "Hypertext Transfer Protocol (HTTP) Field Name
Registry" {{?HTTP=RFC9110}} as shown in the table below:
Registry" {{!HTTP=RFC9110}} as shown in the table below:

|-----------------------|-----------|-----------------|--------------------------------------------|
| Field Name | Status | Structured Type | Reference |
Expand Down