Re: MACs and Signatures (was Re: draft-ietf-httpbis-message-signatures-05)

[Justin Richer <[e-mail]>]

> On Jul 14, 2021, at 12:55 AM, Watson Ladd <[e-mail]> wrote:
> 
> On Tue, Jul 13, 2021 at 5:03 AM Justin Richer <[e-mail]> wrote:
>> <snip> Not only that, but it's supposed to be lower priority than other sources for this info, so if you're doing things right an attacker won't be able to substitute at all.
> 
> Why have it at all? We have been down this road with JWT, and hack
> after hack later, finally sort of maybe learned how to do it right.
> Having this algorithm field invites mischief either through bug or
> doing things wrong, and signing it doesn't help. We should strive for
> specs that cannot be used unsafely, not ones that can be used safely.
> 
> MACs and signatures are not the same. Using them interchangeably is a
> mistake. Letting the signer specify which one to use is a mistake.
> There's really no excuse here: store the signature algorithm with the
> verification key, not in the incoming data to be verified, even if you
> must call HMAC a signature.
> 

I’d argue that both keyed MACs and digital signatures serve the same purpose from an application perspectives, even if the underlying portions are very different from each other, as is the nature of the key material. In this spec, they aren’t interchangeable, they’re usable at the same level. The difference is in the key: If you have an EC key and someone signals an HMAC on a message, that’s an error condition right there and it’s easily detectable. We can — and will — call out known issues like this in the security considerations discussion. We aren’t starting from a vacuum, after all. 

Runtime switching is desirable in some applications and can be handled safely if done well. It’s our goal to have the spec text push people towards defining things either statically at the application level or within the key material’s metadata, and only falling to runtime signals when needed. This is a far cry from the Cavage I-D which said that you always had to have the algorithm field but could ignore it in certain circumstances, during which you’d just “figure it out” from the key, with zero guidance from the spec as to how that was actually supposed to work. The system that we have effectively takes all the best practices from JOSE and other systems and codifies them. The lack of clear primacy was the core cause for bugs in the JOSE world around this field.

Additionally, having named algorithms defined in the spec text also serves to model what is required for application of a signature method to this model: the precision required in these definitions is usually lost on new implementors. Whether or not people use the runtime labels to switch, we want implementors to see what it takes to tie a signature method to an HTTP message.

And besides, I fully believe if we don’t do enable a well-defined way to signal this, someone’s going to just slap an “alg” parameter in there anyway and then start re-making all the mistakes from JOSE from scratch, probably even including “alg: none” again. 

 — Justin