Last Call Review of draft-ietf-httpbis-message-signatures-16
review-ietf-httpbis-message-signatures-16-secdir-lc-migault-2023-02-27-00

Reviewer: Daniel Migault
Review result: Ready

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

Most of the document relies in the specification of the component to be signed.
I have not seen anything suspect but I am far from having the appropriate HTTP
knowledge to say there is no security flaw in the process. To be clear I am not
trying to raise any suspicion there, but if additional security review is
needed, it is, in my opinion,  where the security focus should be put. I also
see that the document has been reviewed by security people with HTTP knowledge,
so I am confident there is no need to have such security concerns.

The document is pretty clear and is well written. Thank you writing it so
clearly.

Yours,
Daniel

Some comments in line:

1.  Introduction

   Message integrity and authenticity are security properties that are
   critical to the secure operation of many HTTP applications.
   Application developers typically rely on the transport layer to
   provide these properties, by operating their application over [TLS].
   However, TLS only guarantees these properties over a single TLS
   connection, and the path between client and application may be
   composed of multiple independent TLS connections (for example, if the
   application is hosted behind a TLS-terminating gateway or if the
   client is behind a TLS Inspection appliance).  In such cases, TLS
   cannot guarantee end-to-end message integrity or authenticity between
   the client and application.
  Additionally, some operating
   environments present obstacles that make it impractical to use TLS,
   or to use features necessary to provide message authenticity.
<mglt>
Maybe we need here to explain why it is impractical. Are you thinking of
signing a component inside the HTTP message. If so, I would say that is a much
stronger reason to have a dedicated mechanisms for HTTP. </mglt>
   Furthermore, some applications require the binding of an application-
   level key to the HTTP message, separate from any TLS certificates in
   use.
<mglt>
I do see TLS as being application-level, so maybe adding beyond transport may
be clearer. Currently we also mention why we need a mechanism that is upper
than TLS, but maybe we should also explain why we cannot simply rely on object
security like JOSE mechanisms. If it does not open doors to controversy, it
might good to close that door. </mglt>
 Consequently, while TLS can meet message integrity and
   authenticity needs for many HTTP-based applications, it is not a
   universal solution.

1.2.  Requirements

   HTTP applications may be running in environments that do not provide
   complete access to or control over HTTP messages (such as a web
   browser's JavaScript environment), or may be using libraries that
   abstract away the details of the protocol (such as the Java
   HTTPClient library (https://openjdk.java.net/groups/net/httpclient/
   intro.html)).  These applications need to be able to generate and
   verify signatures despite incomplete knowledge of the HTTP message.

<mglt>
My personal opinion is that this text is much more convincing than the one of
the introduction. </mglt>

1.4.  Application of HTTP Message Signatures

   *  A means of determining that a given key and algorithm presented in
      the request are appropriate for the request being made.  For
      example, a server expecting only ECDSA signatures should know to
      reject any RSA signatures, or a server expecting asymmetric
      cryptography should know to reject any symmetric cryptography.
<mglt>
The way I am reading this sentence is that the response is signed by the server
and checked by the client. Though I understand the server may also implement an
HTTP client, I am surprised to see the sever rejects what I think are HTTP
responses. I am wondering if I am missing something or if server is used in a
more generic sense as "HTTP entity" and could be a client or a server. In any
case this is a nit. </mglt>

   When choosing these parameters, an application of HTTP message
   signatures has to ensure that the verifier will have access to all
   required information needed to re-create the signature base.  For
   example, a server behind a reverse proxy would need to know the
   original request URI to make use of the derived component @target-
   uri, even though the apparent target URI would be changed by the
   reverse proxy (see also Section 7.4.3).  Additionally, an application
   using signatures in responses would need to ensure that clients
   receiving signed responses have access to all the signed portions of
   the message, including any portions of the request that were signed
   by the server using the related-response parameter.

<mglt>
I do think that it is the most difficult part of the protocol, and to make it
even harder, I am wondering why there is no normative language with a serie of
MUST. This is mostly for my curiosity. </mglt>

2.  HTTP Message Components

   In order to allow signers and verifiers to establish which components
   are covered by a signature, this document defines component
   identifiers for components covered by an HTTP Message Signature, a
   set of rules for deriving and canonicalizing the values associated
   with these component identifiers from the HTTP Message, and the means
   for combining these canonicalized values into a signature base.

   The signature context for deriving these values MUST be accessible to
   both the signer and the verifier of the message.  The context MUST be
   the same across all components in a given signature.  For example, it
   would be an error to use a the raw query string for the @query
   derived component but combined query and form parameters for the
   @query-param derived component.  For more considerations of the
   message component context, see Section 7.4.3.

   A component identifier is composed of a component name and any
   parameters associated with that name.  Each component name is either
   an HTTP field name (Section 2.1) or a registered derived component
   name (Section 2.2).  The possible parameters for a component
   identifier are dependent on the component identifier, and the HTTP
   Signture
<mglt> Sin"a"ture </mglt>

Component Parameters registry cataloging all possible
   parameters is defined in Section 6.5.

   Within a single list of covered components, each component identifier
   MUST occur only once.  One component identifier is distinct from
   another if either the component name or its parameters differ.
<mglt>
English is not my native language, but I am wondering if either or includes
both. I am assuming component names and parameters can be different. from
cambridge dictionary: used to refer to a situation in which there is a choice
between two different plans of action, but both together are not possible:
</mglt>

2.1.  HTTP Fields

   The component name for an HTTP field is the lowercased form of its
   field name as defined in Section 5.1 of [HTTP].  While HTTP field
   names are case-insensitive, implementations MUST use lowercased field
   names (e.g., content-type, date, etag) when using them as component
   names.

   The component value for an HTTP field is the field value for the
   named field as defined in Section 5.5 of [HTTP].  The field value
   MUST be taken from the named header field of the target message
   unless this behavior is overridden by additional parameters and
   rules, such as the req and tr flags, below.
   Unless overridden by additional parameters and rules, HTTP field
   values MUST be combined into a single value as defined in Section 5.2
   of [HTTP] to create the component value.  Specifically, HTTP fields
   sent as multiple fields MUST be combined using a single comma (",")
   and a single space (" ") between each item.  Note that intermediaries
   are allowed to combine values of HTTP fields with any amount of
   whitespace between the commas, and if this behavior is not accounted
   for by the verifier, the signature can fail since the signer and
   verifier will be see
<mglt> will see </mglt>

a different component value in their respective
   signature bases.  For robustness, it is RECOMMENDED that signed
   messages include only a single instance of any field covered under
   the signature, particularly with the value for any list-based fields
   serialized using the algorithm below.  This approach increases the
   chances of the field value remaining untouched through
   intermediaries.
<mglt>
For my own information, I am wondering why having a signature over two
instances of the same field increases over a single instances increases the
chances of the field - one of the fields being modified on path. </mglt>

2.2.4.  Scheme

   The @scheme derived component refers to the scheme of the target URL
   of the HTTP request message.  The component value is the scheme as a
   lowercase string as defined in [HTTP], Section 4.2.  While the scheme
   itself is case-insensitive, it MUST be normalized to lowercase for
   inclusion in the signature base.

   For example, the following request message requested over plain HTTP:

   POST /path?param=value HTTP/1.1
   Host: www.example.com

   Would result in the following @scheme component value:

   http

   And the following signature base line:

   "@scheme": http

<mglt>
For my information, I am wondering how the signer can distinguish the http
scheme from https as it does not appear in the HTTP message. Since we only deal
with HTTP, I am wondering if the https scheme is not replaced by http. </mglt>

2.2.5.  Request Target

<mglt>
For my information I am wondering how one can make the target unique. typically
do we include the port even when the default port is being used and thus can be
omitted ? </mglt>

7.1.2.  Use of TLS

   The use of HTTP Message Signatures does not negate the need for TLS
   or its equivalent to protect information in transit.  Message
   signatures provide message integrity over the covered message
   components but do not provide any confidentiality for the
   communication between parties.

   TLS provides such confidentiality between the TLS endpoints.  As part
   of this, TLS also protects the signature data itself from being
   captured by an attacker, which is an important step in preventing
   signature replay (Section 7.2.2).

   When TLS is used, it needs to be deployed according to the
   recommendations in [BCP195].

<mglt>
signature is only focused on authentication and TLS 1.3 always has encryption,
so the overlap remains only in the case a NULL cipher would be use. My
understanding of OSCORE is that it restricts the protection of the header and
that authentication only is permitted, this make it potentially a more
interesting protocol in term of overlap. I have the impression you are able to
achieve in term of integrity similar protection as OSCORE as the HTTP signature
can include headers fields. I am wondering it that would worth being mentioned.
</mglt>

7.2.2.  Signature Replay

   Since HTTP Message Signatures allows sub-portions of the HTTP message
   to be signed, it is possible for two different HTTP messages to
   validate against the same signature.  The most extreme form of this
   would be a signature over no message components.  If such a signature
   were intercepted, it could be replayed at will by an attacker,
   attached to any HTTP message.  Even with sufficient component
   coverage, a given signature could be applied to two similar HTTP
   messages, allowing a message to be replayed by an attacker with the
   signature intact.

<mglt>I see this as a repeat of 7.2.1. </mglt>

   To counteract these kinds of attacks, it's first important for the
   signer to cover sufficient portions of the message to differentiate
   it from other messages.  In addition, the signature can use the nonce
   signature parameter to provide a per-message unique value to allow
   the verifier to detect replay of the signature itself if a nonce
   value is repeated.  Furthermore, the signer can provide a timestamp
   for when the signature was created and a time at which the signer
   considers the signature to be expired, limiting the utility of a
   captured signature value.

   If a verifier wants to trigger a new signature from a signer, it can
   send the Accept-Signature header field with a new nonce parameter.
   An attacker that is simply replaying a signature would not be able to
   generate a new signature with the chosen nonce value.

<mglt>I do see two different problem here: 1) Do I have the signature of the
message ? and 2) Do I have the signature of the response ? I do see the first
remain related to 7.2.1 and the cookie solving 2. 1) enable caching and might
be relevant for public data - for the time that public data is valid. In both
cases there is a replay I agree, but I am wondering if there is any
recommendation regarding the use of the new nonce.</mglt>

7.2.8.  Message Content

   As discussed in [DIGEST], the value of the Content-Digest field is
   dependent on the content encoding of the message.  If an intermediary
   changes the content encoding, the resulting Content-Digest value
   would change, which would in turn invalidate the signature.  Any
   intermediary performing such an action would need to apply a new
   signature with the updated Content-Digest field value, similar to the
   reverse proxy use case discussed in Section 4.3.

<mglt> This seems to suggest some sort of policies. For my information I am
wondering current implementations are using such policies to configure the
validator or if that is "left to the implementation" meaning we trust somehow
the signer to perform the correct operation. </mglt>

7.3.1.  Cryptography and Signature Collision

   The HTTP Message Signatures specification does not define any of its
   own cryptographic primitives, and instead relies on other
   specifications to define such elements.  If the signature algorithm
   or key used to process the signature base is vulnerable to any
   attacks, the resulting signature will also be susceptible to these
   same attacks.

Backman, et al.          Expires 10 August 2023                [Page 70]

Internet-Draft           HTTP Message Signatures           February 2023

   A common attack against signature systems is to force a signature
   collision, where the same signature value successfully verifies
   against multiple different inputs.  Since this specification relies
   on reconstruction of the signature base from an HTTP message, and the
   list of components signed is fixed in the signature, it is difficult
   but not impossible for an attacker to effect such a collision.  An
   attacker would need to manipulate the HTTP message and its covered
   message components in order to make the collision effective.

<mglt> Note being familiar enough with HTTP, the attack is especially an issue
if the client is able to predict the HTTP response, - and echo server is a good
example. I am wondering what the server could respond in order to differ from
the expected responses. one way to see that is to make any response
unique.</mglt>

7.5.5.  Canonicalization Attacks

   Any ambiguity in the generation of the signature base could provide
   an attacker with leverage to substitute or break a signature on a
   message.  Some message component values, particularly HTTP field
   values, are potentially susceptible to broken implementations that
   could lead to unexpected and insecure behavior.  Naive
   implementations of this specification might implement HTTP field
   processing by taking the single value of a field and using it as the
   direct component value without processing it appropriately.

   For example, if the handling of obs-fold field values does not remove
   the internal line folding and whitespace, additional newlines could
   be introduced into the signature base by the signer, providing a
   potential place for an attacker to mount a signature collision
   (Section 7.3.1) attack.  Alternatively, if header fields that appear
   multiple times are not joined into a single string value, as is
   required by this specification, similar attacks can be mounted as a
   signed component value would show up in the signature base more than
   once and could be substituted or otherwise attacked in this way.

   To counter this, the entire field value processing algorithm needs to
   be implemented by all implementations of signers and verifiers.

<mglt>
In the canonicalization process, I would like to know if we have a simple way
to ensure that Cannonicalization( HTTP field1: HTTP_value1 ) will never ends in
Cannonicalization( HTTP fielda: HTTP_valuea \n HTTP fieldb: HTTP_valueb )

I have the impression this is the main potential source of weakness this
document may introduce. Note that I am not familiar with HTTP, so do not be
upset if the question is straight forward and obvious. I think the reason I
have this in mind is that some separators are replaced during the
canonicalization.

</mglt>