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

+1

Target URI and Method (as well as other data related to the message), may equally well be put in the payload.  HTTP header signing is an unnecessary complication.

Anders

On 2022-10-16 23:56, Dick Hardt wrote:
> 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/* <https://www.example.com/api/v1/*> the CDN may proxy the call to https://v1.api.example.com/* <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/* <https://www.example.com/api/v1/people/*> to http://people <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
> 
>

Received on Monday, 17 October 2022 10:45:09 UTC