Skip to main content

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

Request Review of draft-ietf-httpbis-message-signatures
Requested revision No specific revision (document currently at 19)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2021-07-31
Requested 2021-06-19
Requested by Mark Nottingham
Authors Annabelle Backman , Justin Richer , Manu Sporny
I-D last updated 2021-07-30
Completed reviews Secdir Telechat review of -17 by Daniel Migault (diff)
Artart Telechat review of -17 by Harald T. Alvestrand (diff)
Secdir Early review of -05 by Daniel Migault (diff)
Artart Last Call review of -16 by Harald T. Alvestrand (diff)
Opsdir Last Call review of -16 by Bo Wu (diff)
Secdir Last Call review of -16 by Daniel Migault (diff)
Genart Last Call review of -16 by Dan Romascanu (diff)
Comments
This is a request for an early, high-level review of this document, with focus on how it uses cryptography and whether it reflects current best practice. 

We have multiple people with security and cryptography experience participating in the effort, but as always more eyes are an advantage.

The Security Considerations are *not* complete yet. The deadline above is soft (the tool just makes us put something there).
Assignment Reviewer Daniel Migault
State Completed
Request Early review on draft-ietf-httpbis-message-signatures by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/7cZmqYbU_15I2-49eFgzSOWT4Hk
Reviewed revision 05 (document currently at 19)
Result Has issues
Completed 2021-07-30
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>