Re: Signature Authentication Scheme

[David Schinazi <[e-mail]>]

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

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