RE: Secdir early review of draft-ietf-httpbis-message-signatures-05

Thank you for the review, these are all excellent comments and we'll incorporate them into the next drafts.

- Justin
________________________________________
From: Mark Nottingham [mnot@mnot.net]
Sent: Saturday, July 31, 2021 12:48 AM
To: Daniel Migault
Cc: secdir@ietf.org; draft-ietf-httpbis-message-signatures.all@ietf.org; ietf-http-wg@w3.org
Subject: Re: Secdir early review of draft-ietf-httpbis-message-signatures-05

Thanks for the review, Daniel - much appreciated.


> On 31 Jul 2021, at 8:49 am, Daniel Migault via Datatracker <noreply@ietf.org> wrote:
>
> Reviewer: Daniel Migault
> Review result: Has Issues
>
> 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>
>
>
>

--
Mark Nottingham   https://www.mnot.net/

Received on Saturday, 31 July 2021 11:39:21 UTC