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

[Roman Danyliw via Datatracker <[e-mail]>]

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?

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

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

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