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

[Watson Ladd <[e-mail]>]

On Wed, Jul 14, 2021 at 12:28 PM Justin Richer <[e-mail]> wrote:
>
>
>
> > 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.

If the only possible value for the algorithm field is determinable
from the key, why have the algorithm field in the message? It's not
adding information. The only way to use it is to misuse it. They also
don't work the same way for an application: a signature can be
verified by anyone, a MAC only by someone capable of computing it,
which means they can forge it. Very different security considerations
which matter to what kinds of applications can use what safely.  Now
that doesn't mean one can't have the same spec support both, but the
language really does matter.

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

Which applications, what kind of switching? If it's identifying the
key in the signed data, that can be done, but the algorithm must
travel with the key, not the message. Why is indicating the algorithm
in the signed data necessary? Could you please provide examples of
applications that need it?

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

Then eliminate the runtime indication entirely. There is no way in
which changing the algorithm used with a key is ever correct without
exacting analysis.

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

No, the cause for bugs was the garden path the spec presented by
having an invitation to disaster.

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

You can define algorithms without having them in what is sent over the wire.

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

My understanding of your argument: because someone might do something
unnecessary and a security risk, we should do the first step of the
unnecessary and security risk thing (adding alg), and tell them not to
do the second (looking at it) instead of telling them it is a terrible
idea and explaining why. I believe that we can do better to guide
people to the right approach.

Sincerely,
Watson Ladd

>
>  — Justin



-- 
Astra mortemque praestare gradatim