Re: Roman Danyliw's No Objection on draft-ietf-httpbis-digest-headers-12: (with COMMENT)

Hi Roman,

Thanks for the review. Responses in line:


On Tue, May 23, 2023 at 6:48 PM Roman Danyliw via Datatracker <
noreply@ietf.org> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-httpbis-digest-headers-12: 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-digest-headers/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you to Peter Yee for the SECDIR review.
>
> ** Section 2.  Using multiple digests in a single Content-Digest is
> supported.
> There is also guidance that “a recipient MAY ignore any or all of the
> digests”.
>  I read that text as “if presented multiple digests, a recipient can
> choose to
> look at only one or some subset of the digests.” Is that accurate?  Is
> there
> standardized behavior for when a recipient validates/checks both digests
> and
> only one is valid?
>

Background caveats: we are building on top of the way that RFC3230 did
things, which was quite relaxed about stating what the receiver
requirements are. In this draft, validation failures are primarily an
implementation concern. In other words, the decision about what to do with
a validation failure are the concern of the application using this HTTP
capability. There's an interplay with general-purpose HTTP feature
discovery too, which is not really great and we can't solve.

In the case you highlight, I interpret that as a receiver that does want to
check digest, and it receives more than one value that it supports the
algoithm of. Since we don't really standardise what to do when even a
single digest validation fails, I'm not sure what we can really say, from a
standards perspective, if one succeeds or one fails.

Spamming the receiver with digest values is a possible attack that we give
some consideration in Section 6.7. So I'm cautious about making anything
appear as if a receiver has to cross verify the integrity digests.


> ** Section 4.
>    *  key conveys the hashing algorithm (see Section 5);
>
> Shouldn’t this read as “hashing algorithm(s)” as it is possible to send
> more
> than one in the field?
>

The full text is

> Want-Content-Digest and Want-Repr-Digest are of type Dictionary where
each:
-
> * key conveys the hashing algorithm (see Section 5
<https://httpwg.org/http-extensions/draft-ietf-httpbis-digest-headers.html#algorithms>
);

Just to establish we're on the same page. A Structured Fields Dictionary is
a set of individual items that have a key. A key indicates a single
algorithm. If the sender wants to indicate multiple algorithms, it sends
multiple keys.

If we didn't have the "each" qualifier on the preceding line, I'd agree
that "keys" could be used. But I find the current presentation clearer from
an editorial perspective.


> ** Section 4.
>    *  value is an Integer (Section 3.3.1 of [STRUCTURED-FIELDS]) that
>       conveys an ascending, relative, weighted preference.  It must be
>       in the range 0 to 10 inclusive. 1 is the least preferred, 10 is
>       the most preferred, and a value of 0 means "not acceptable".
>
> -- Can multiple algorithms share the same preference value?  For example,
> could
> multiple algorithms be labeled “not acceptable”?
>
> -- If yes, would their ordering determine preference?
>

Yes they can have the same value.

We had a issue for this and concluded to not say anything specific about
preference, which aligns with existing HTTP semantics. See
https://github.com/httpwg/http-extensions/issues/2389.


> ** Section 6.1.  Recommend adding cautionary language about the
> capabilities of
> an adversary like those stated in Peter’s SECDIR review.  Perhaps:
>
> OLD
>    Integrity fields are not intended to be a general protection against
>    malicious tampering with HTTP messages. This can be achieved by
>    combining it with other approaches such as transport-layer security
>    or digital signatures (for example, HTTP Message Signatures
>    [SIGNATURES]).
>
> NEW
> Integrity fields are not intended to be a general protection against
> malicious
> tampering with HTTP messages. In the absence of additional security
> mechanisms,
> an on-path, malicious actor can remove or recalculate and substitute a
> digest
> value.  This attack can be mitigated by combining mechanisms described in
> this
> document with other approaches such as transport-layer security or digital
> signatures (for example, HTTP Message Signatures [SIGNATURES]).
>

Thank you for this suggestion, we'll incorporate this into the editor's
copy.

Cheers,
Lucas