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>