feedback on draft-ietf-httpbis-message-signatures-13

Hello

I have feedback on the positioning of HTTP Message Signatures, and am
sharing some history on message signing.

FWIW I do *not* plan to implement or support HTTP Message Signatures
(presuming  I have a choice)

*Draft Feedback*
Section 1.4

"HTTP Message Signatures are designed to be a general-purpose security
mechanism applicable in a wide variety of circumstances and applications. "


This is a very broad statement. While true, there is no guidance to an
implementer when HTTP Message Signatures would be preferable to other
signature mechanisms. For example, if one only needs to sign the payload,
JOSE and COSE are widely deployed and available mechanisms to ensure
message integrity, and have the added benefit of supporting message
secrecy.

The one use case where HTTP Message Signatures are differentiated from JOSE
and COSE is that HTTP headers in addition to the payload can be signed.
From what I glean from the examples, the @target-uri and @method seem to be
the most interesting. (please add more examples if there are others!).
These message attributes are often critical to a web API, and the desire to
provide integrity of these attributes is clear as there the integrity of
the client's intent is preserved through intermediaries -- or so would seem.

There are a number of common deployment models where HTTP Message Signature
will not preserve @target-uri as the @target-uri is different at the
application server than what the client called.

One of these is where a CDN such as CloudFront serves both static and
dynamic content. The CDN routes requests that match certain paths to
different hosts. For example when receiving a call to
https://www.example.com/api/v1/* the CDN may proxy the call to
https://v1.api.example.com/*

Another is where messages are routed between microservices. A message
router may route calls to https://www.example.com/api/v1/people/* to
http://people within the services network.

In these two examples, using JOSE or COSE and including the @target-uri and
@method values in the payload would provide the desired
integrity protection, and optionally enable secrecy with end to end
encryption.

*Message Signing Experience*

I provide the following stories as a cautionary tale on the challenges of
message signing.

Remember XML-DSig? I do. One of my ventures took on a consulting contract
to write XML-DSig libraries for a number of popular languages. While the
OSS libraries we shipped all worked -- the canonicalization was non-trivial
and if I recall, there were a number of non-deterministic flows. I don't
see XML-DSig used in the wild anymore besides SAML.

OAuth 1.0 was another example of a painful message signing standard. The
initial group did not want to require HTTPS -- so they sort of reinvented
it. Despite the development of libraries to use, developers had challenges
in getting it all working. I recall having code that called Twitter APIs
(one of the last OAuth 1.0 holdouts) that would work
intermittently depending on which one of the Twitter load balancers I hit.

I led the design on what became OAuth 2.0 primarily because of the message
signing concerns. The first requirement we agreed to was requiring HTTPS.

My experience with XML-DSig and the messaging signing challenges of OAuth
1.0 were key inputs in the design work I did on what became JOSE. One of
the first requirements was no canonicalization. Take the JSON string as is
and base64url encode it. Done.

/Dick