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

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 [chris@langton.cloud]
Sent: Monday, July 12, 2021 1:44 AM
To: public-credentials@w3.org; ietf-http-wg@w3.org
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

Received on Tuesday, 13 July 2021 11:59:42 UTC