Early Review of draft-ietf-httpbis-message-signatures-05
review-ietf-httpbis-message-signatures-05-secdir-early-migault-2021-07-30-00

Hi,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

The main issue I have is the absence of security considerations ;-), but
otherwise the text appears to me quite clear. I will review the document once
the security consideration is completed.

I do not see the document mentioning any sort of negotiation which limits the
scope of possible downgrade attacks or the ability from one party to
"orchestrate" in some ways, what the other party. In other words, if I did not
missed anything the signature is a local policy. This typically means that a
client may sign while responses may not be signed.  Section 1.5 defines what
needs to be agreed between multiple parties, but does not provides details how
this could be achieved.

Some very minor editorial comments.
section 1.4
<mglt>
   The qualified term "digital
   signature" refers specifically to the output of an asymmetric
   cryptographic signing operation.

May be that would be clearer to define digital signature before mentioning
"signature" is used for both digital signature and Keyed MAC. </mglt>

section 1.5
   *  The set of content identifiers (Section 2) that are expected and
      required.
<mglt>
I suppose that the content are security related, but it is unclear at least to
me at this stage if the content have any kind of limitation. Typically, if a
party is able require an specific header that leaks private information, that
may be an issue. I think the text might be able to clarify this.

Though I expected it to be detailed later and "expected" security related
information is always suspicious of ending in a best effort situation where
security is optional. These are simply what come to my mind when reading these
lines. There is no necessary some actions to be taken if you believe that is
not necessary. </mglt>

section 2.4
<mglt>
   If covered content references an identifier that cannot be resolved
   to a value in the message, the implementation MUST produce an error.
   Such situations are included but not limited to:

   *  The signer or verifier does not understand the content identifier.

   *  The identifier identifies a header field that is not present in
      the message or whose value is malformed.

If the value is malformed, it may indicate that the value is interpreted
previously the integrity has been checked. I am sure this is not what the text
is meaning, but this is how I read it, so I believe that some clarification may
be needed. </mglt>