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

Dear all,

Thanks for the review. Responses in line:

On Tue, 23 May 2023 at 21:50, Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:
> 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.

Agree with Lucas.


>> ** 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);
>
>
> 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.

Agree with Lucas.

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

Agree with Lucas.

>> ** 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]).

Thanks for this suggestion! I filed a PR which includes it:

- https://github.com/httpwg/http-extensions/pull/2554/files#diff-de34152d297a9eb29b85b24962949ba2e309478a5c32e1d94fd4c3ee27b4584dR522

Thanks again and have a nice day,
R.

Received on Wednesday, 24 May 2023 08:45:03 UTC