Re: Signature Authentication Scheme

[Ben Schwartz <[e-mail]>]

Bikeshed: Given that this scheme is limited to use with TLS, I think the scheme name (and perhaps also the document title) should include "TLS".

--Ben
________________________________
From: David Schinazi <[e-mail]>
Sent: Sunday, March 17, 2024 1:58 AM
To: Justin Richer <[e-mail]>
Cc: HTTP Working Group <[e-mail]>
Subject: Re: Signature Authentication Scheme

Hi Justin, thanks for your comments. Responses inline. David On Sat, Mar 16, 2024 at 4: 59 AM Justin Richer <jricher@ mit. edu> wrote: I talked with David Oliver this morning at the hackathon, and I would like to raise some concerns about
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender

ZjQcmQRYFpfptBannerEnd
Hi Justin, thanks for your comments. Responses inline.
David

On Sat, Mar 16, 2024 at 4:59 AM Justin Richer <[e-mail]<mailto:[e-mail]>> wrote:
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.

For what it's worth, the draft isn't "HTTP Signature Authentication", it's "The Signature HTTP Authentication Scheme". That said, if you feel there's confusion then this can definitely be approved. I'm not opposed to changing the name if we find something that makes sense. How would you feel about "A Signature-Based HTTP Authentication Scheme" or "HTTP Authentication Using Signatures"? Though this might be moot if we rename the scheme - see below.

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).

Thanks for flagging this, I was not aware of this prior use at all. Given that the current implementations haven't yet widely deployed, it's not too late to change the scheme. One potential option could be to lean into the prior name of the draft and use the scheme "UnpromptedSignature". Then the title of the document could be "The UnpromptedSignature HTTP Authentication Scheme", which would also be less confusing.

Thoughts on that scheme name? Other proposals for different names?

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.

The compelling reason is that HTTP authentication parameters have a restricted set of characters that don't allow the unescaped colons required by sf-binary. A previous version of the draft wrapped this with double-quotes to make it both a structured field and a valid authentication parameter (it looked like ":foobar:"), but the WG decided to not do that and instead remove structured fields.

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.

Thanks for the suggestion. I had reviewed the draft that became RFC 9421 back in the day, and I just looked through the relevant parts again. I don't think it makes sense to reuse it here. The focus then was on normalizing semantics that can be encoded multiple ways, and that's not a useful feature here. While there's often value in reusing existing tools, none of the four implementations of draft-ietf-httpbis-unprompted-auth have an implementation of RFC 9421, so we'd be adding complexity instead of leveraging synergy.