Re: Signature Algorithm Identifiers

> simpler for developers to pick the “latest” date of an algorithm as more secure

A common argument in the current NIST PQC standardization is that older is better :)


> - rsa-v1_5-sha256
> - rsa-pss-sha512
> - hmac-sha256
> - ecdsa-p256-sha256

This seems to treat the algorithms differently. ecdsa-p256-sha256 always gives 128-bit security. I assume hmac-sha256 will use a 256-bit keys and then it will also give 128-bit security. The two RSA algorithms on the other hand seems to be have variable security levels depending on the key, maybe good to lock them to 3072-bit keys.

On the other hand, I find binding a signature algorithm to a specific type of key strange. It is the key usage that should be restricted, not the other way around.

A bit strange to see RSASSA-PKCS1-v1_5 (RFC 8017) but not Ed25519 (RFC 8032) in a new standard.

Cheers,
John

From: Justin Richer <jricher@mit.edu>
Date: Friday, 18 June 2021 at 22:54
To: ietf-http-wg@w3.org Group <ietf-http-wg@w3.org>
Subject: Signature Algorithm Identifiers
As discussed on the interim call this week, there’s a proposal for changing the algorithm identifiers used in the message signatures draft. There was spirited discussion on the topic, which I’ll try to summarize here, and it’s been discussed in the following issue:

https://github.com/httpwg/http-extensions/issues/1510<https://protect2.fireeye.com/v1/url?k=84cb0821-db50311d-84cb48ba-86b1886cfa64-f3075bc03b2c1031&q=1&e=8ff6f9a3-b0f9-4e44-a984-4608851a30f7&u=https%3A%2F%2Fgithub.com%2Fhttpwg%2Fhttp-extensions%2Fissues%2F1510>

First, please note that we are only talking about the algorithm identifiers, not the algorithm definitions. The identifiers are simple strings, not parsed structures. Their job is to convey to an implementor a unique value that can be dereferenced to a fully-defined algorithm definition; the definition would include the parameters, the identifier does not. Also, note that the algorithm identifiers are optional within the protocol. Message signatures explicitly allows ANY signature method to be used if known by both parties, and the algorithm identifiers are there solely for the purpose of identifying a known algorithm at runtime against a set of publicly known fixed values in a registry.

The editors have defined the following identifiers in the current draft, to be used with fully-specified cryptographic algorithms:

- rsa-v1_5-sha256
- rsa-pss-sha512
- hmac-sha256
- ecdsa-p256-sha256

Additional algorithms can be defined in an IANA registry, and as stated above, applications are free to use their own signature algorithms without registering a code point.

The counter-proposal in question (at the issue above) proposes a date-based method for identifiers instead (replacing each identifier in the above list respectively):

 - rsa-2003
 - rsa-2005
 - hmac-2006
 - ecdsa-2013

Summarizing some of the arguments for and against presented on the call:

In favor:
 - simpler for developers to pick the “latest” date of an algorithm as more secure
 - developers will pick a higher number without having to understand the differences
 - can “nudge” the community to using better algorithms through labeling
 - can register new date identifiers to “refresh” best practice definitions
 - names are shorter and don’t look like cryptographic primitives

In opposition:
 - date is a poor stand-in for a quality metric
 - developers will pick a higher number without understanding differences
 - newer algorithms and profiles aren’t necessarily “better” than older ones
 - if a community-specific profile is defined later, like rsa-2024 for IoT devices, it could lead to developers choosing poorly-fit security
 - developers still need to know the difference between RSA, hmac, ecdsa, etc, otherwise “hmac-2006” looks universally better than “rsa-2005”
 - proposed names are not generally known or meaningful to  cryptography experts and developers, while current names are descriptive and recognizable to them
 - namespace collision if two profiles are published within a single year

What stays the same in both cases:
 - Algorithm parameters are defined in a document paragraph referenced from the identifier (the identifier itself does not define parameters)
 - Algorithms must be fully defined in a standard to be registered
 - Applications can still use whatever they want and avoid the named algorithm field entirely

The sentiment on the call seemed fairly clear, but the editors are seeking feedback and consensus as to whether the registered draft should switch to the date-based identifier format as proposed or to keep the current labels.

Thank you,
 — Justin