Signature Authentication Scheme

[Justin Richer <[e-mail]>]

I talked with David Oliver this morning at the hackathon, and I would like to raise some concerns about the "Signature Authentication Scheme" draft (draft-ietf-httpbis-unprompted-auth) that mostly revolve around the positioning of the draft in the larger ecosystem.

As many of you know, we recently published HTTP Message Signatures as RFC9421 (huge thanks to the working group and everyone that helped out!). That draft was over four years of work here in HTTP and many more years longer than that floating around in various incompatible I-D’s. It’s in this context that I am providing this feedback.

1: The title of the draft and use of "HTTP Signature"

The draft draft-ietf-httpbis-unprompted-auth has no relationship whatsoever to RFC9421, in spite of a very similar name. The mechanism in draft-ietf-httpbis-unprompted-auth is not about signing the HTTP message itself (apart from the scheme/host/port exported form TLS in section 4.1), but about presenting a signature value to the server in the request. This signature is intended to be bound to the target URI of the request, regardless of what the request itself is. Furthermore, the method is restrained to a single hope as it is based on binding to TLS level key material (see section 8).  Additionally, the draft currently defines a single algorithm for use, without cryptographic agility.

This list is not meant a judgement on these choices, but rather to contrast with the choices made in RFC9421, which targets arbitrary portions of the message, does not constrain key material to the TLS connection, can be used through intermediaries, and provides a robust cryptographic agility and extension mechanism.

At the very least, this draft needs to clearly differentiate itself from RFC9421 in both the introduction and relevant portions of the text. Even better, in my personal opinion, this draft should be called something different. It :uses: signatures to accomplish a specific goal similar to HOBA, but it does not provide a signature mechanism for HTTP.

2: The use of the "Signature" authentication scheme

In draft-cavage-http-signatures, which was one of the precursor inputs to RFC9421, there is a "Signature" authentication scheme defined in Section 3. In RFC9421, we deliberately removed this feature, as the goal of RFC9421 was to specify a mechanism for signing requests and responses and not for presenting those signatures as authentication or authorization, which would be higher-level protocols.

This would ostensibly mean that the "Signature" authentication scheme is up for grabs, but the truth of the situation is that the Cavage draft saw wide adoption of its various versions long before the HTTP WG picked up work on what became RFC9421. This means that there are existing ecosystems depending on their own definition of a "Signature" authentication scheme. When this draft is deployed, that collision is going to be a painful one. Furthermore, a naive developer would see this draft and grab a Cavage library to try and implement it.

I believe that this draft should use a different scheme, both to avoid conflict with Cavage implementations and also in concert with the reasons for naming choices in (1).

3: The field format and syntax

This draft defines its own field format and parameter encoding, based on base64url. As the values in question are binaries with labels, this is ripe for using structured fields. Is there a compelling reason not to? The syntax is ALMOST there as it stands today, so implementations wouldn’t need to change much in practice — but new implementations could rely on structured fields to provide parsing and serialization in a less error prone way.

4: Compatibility with RFC9421

And finally, this draft invents its own signature base string generator and signature calculation method separate from RFC9421. It is neither necessary nor expected for all new drafts to follow the methods in RFC9421, but I believe it would be worth at least exploring if the corresponding parts of RFC9421 could be used in here. I have a feeling that the answer is "not really", or more likely "we could but it makes this specific use case way more complicated than it’s worth", and that is a reasonable outcome — but I’d like to see that this work has at least been considered.

— Justin