Subject: RE: draft-ietf-httpbis-message-signatures-05

From: Justin Richer <[email-masked]>
Date: Tue, 13 Jul 2021 11:59:23 +0000

We do not intend to deprecate this, and we are not ignoring lessons from the Cavage draft. It appears on the surface that this is a typical "deprecate unsafe crypto" move that we're reversing, but that isn't what happened. 

The real reason is a little buried: If you look more closely at the deprecation message in the text you have below, you can see that HMAC was deprecated in the Cavage draft not because of security concerns with HMAC or SHA256, but in specifying the algorithm on the wire: "specifying signature algorithm enables attack vector". The same text is applied to all other algorithms except the pseudo-algorithm of "hs2019" which does not specify anything beyond "look at the key and figure it out". The Cavage draft had a required "algorithm" parameter that was unsigned. The algorithms themselves are also deeply under specified. This is a bad combination that can lead to substitution attacks in certain circumstances (though I am not aware of any in the wild). 

In the WG draft, a number of things have changed to address this. First, the algorithm parameter is optional, and there's a more clear process to determine the algorithm to use in a given message. If you know this information from static configuration, or the key material, or the application layer, then you don't need and don't use the runtime parameters. In fact you can use whatever algorithm you want in that case and it doesn't need to be registered, it's up to the application to choose. If you do need the runtime parameter it's there with strictly defined values and methods, and it is signed as part of the signature process. 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. 

Functionally, it's very similar to the state of the Cavage draft but without the wonky pseudo algorithm identifier. We changed the structures and removed the hacks. It's our hope and plan that things are much clearer now for developers.

As for the other HMAC values below, I'd be fine with registering these, but I'd like more feedback from the crypto and developer communities. Plus we'd need the specific text to include to define the algorithms registered, like the current algorithm identifiers have. 

Thanks for bringing up this topic! If anything I said here can be made more clear, please let me know what we can do. 
- Justin
________________________________________
From: Christopher Langton [[email-masked]]
Sent: Monday, July 12, 2021 1:44 AM
To: [email-masked]; [email-masked]
Subject: draft-ietf-httpbis-message-signatures-05

I noticed that in this draft-ietf-httpbis-message-signatures-05 that has replaced expired draft-cavage-http-signatures-08 did not adopt many of the learning of it's predecessor, specifically regarding HMAC.

This draft currently accepts HMAC-SHA256 however I recall reading draft-cavage dropped supporting that in earlier versions (9 or 10)

Algorithm Name: hmac-sha256
Status: deprecated, specifying signature algorithm enables attack
vector.
Canonicalization Algorithm: [RFC_THIS_DOCUMENT], Section 2.3<https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12#section-2.3>:
Signature String Construction [25<https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12#ref-25>]
Hash Algorithm: RFC 6234<https://datatracker.ietf.org/doc/html/rfc6234> [RFC6234<https://datatracker.ietf.org/doc/html/rfc6234>], SHA-256 (SHA-2 with 256-bits of
digest output)
Message Authentication Code Algorithm: RFC 6234<https://datatracker.ietf.org/doc/html/rfc6234> [RFC6234],
Section 7.1<https://datatracker.ietf.org/doc/html/rfc6234#section-7.1>: SHA-Based HMACs

and version 12 uses SHA512.
Is it fair to assume draft-ietf-httpbis-message-signatures-06 i.e. next version, will deprecate HMAC-SHA256 also?

Might i suggest supporting any of the following, because they are 'interchangeable' in implementation level detail; in openssl and majority of programming languages (and all libraries) that support a HMAC in the standard crypto construct.

HMAC-SHA512
HMAC-SHA3-256
HMAC-SHA3-384
HMAC-SHA3-512
HMAC-BLAKE2B512

I have a proof of concept in Golang and ruby in a past employer, and have my own proof of concepts showing they are also interchangeable in bash using openssl, python using hashlib, nodejs using crypto, and JavaScript using Crypto.JS.

I hope this is accepted, I am looking forward to HTTP signed requests getting publiched out of draft and more widely adopted, because alternatives are overly complex (implementation level) or offer some security charade (Hawk Authentication).
This technical spec is a great balance of complex security characteristics and knowledge of the necessary implementation developers will need to do.

Regards
Christopher Langton

---

From: Watson Ladd <[email-masked]>
Date: Tue, 13 Jul 2021 21:55:16 -0700

On Tue, Jul 13, 2021 at 5:03 AM Justin Richer <[email-masked]> 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.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim

---

From: Justin Richer <[email-masked]>
Date: Wed, 14 Jul 2021 15:28:51 -0400

> On Jul 14, 2021, at 12:55 AM, Watson Ladd <[email-masked]> wrote:
> 

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

---

From: Watson Ladd <[email-masked]>
Date: Wed, 14 Jul 2021 13:19:46 -0700

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

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…

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

---

From: Nikos Fotiou <[email-masked]>
Date: Thu, 15 Jul 2021 16:32:37 +0300

A minor comment

> On 14 Jul 2021, at 11:19 PM, Watson Ladd <[email-masked]> wrote:
> 

With MAC no key is sent. So you need somehow to indicate the MAC algorithm.