SHA-3 and HMAC keygen

[panva]

dictionary HmacKeyGenParams : Algorithm {
  required HashAlgorithmIdentifier hash;
  [EnforceRange] unsigned long length;
};

The hash member represents the inner hash function to use.

The length member represent the length (in bits) of the key to generate. If unspecified, the recommended length will be used, which is the size of the associated hash function's block size.

In Node's initial implementation I've used the rate (R) SHA-3's sponge construction to inform the default HMAC length.

That is

SHA3-256: Rate (R) = 1088 bits
SHA3-384: Rate (R) = 832 bits
SHA3-512: Rate (R) = 576 bits

But it seems counter-intuitive that the larger the SHA is the shorter the key would be.

The alternative would be to use the Capacity (C) which is 1600-R

SHA3-256: Capacity (C) = 512 bits
SHA3-384: Capacity (C) = 768 bits
SHA3-512: Capacity (C) = 1024 bits

Can we clarify which is right to use as the default HmacKeyGenParams when SHA-3 hash is used?

[twiss]

Yeah, that's a good question. If we want to be consistent with SHA-2, the latter seems more sensible.

However, I actually think that the original recommendation / default is based on a misreading of RFC 2104, which says:

(...) the minimal recommended length for K is L bytes (as the hash output length).

(section 2), and

The key for HMAC can be of any length (keys longer than B bytes are
first hashed using H). However, less than L bytes is strongly
discouraged as it would decrease the security strength of the
function. Keys longer than L bytes are acceptable but the extra
length would not significantly increase the function strength. (A
longer key may be advisable if the randomness of the key is
considered weak.)

(section 3)

In other words, a high-entropy random key of the size of the hash output is sufficient and apparently recommended.

So, we could say that the recommended and default size is the size of the hash digest, except for SHA-2 and SHA-1 the default is the block size, for backwards compatibility?

(As an aside, HMAC using SHA-3 is somewhat overkill so I don't think there's really any reason to use it over KMAC or even just plain SHA-3, but that being said it's also not insecure so I also don't see a strong reason to disallow it entirely. But, if we want to punt this question until we merge it into the main spec, we could also say for now that interactions with the existing algorithms are not yet defined.)

[emanjon]

Note that an agreed errata to RFC 2104 is:

"Applications MUST not use keys longer than B bytes."
https://www.rfc-editor.org/errata_search.php?rfc=2104

I would personally ignore RFC 2104 and instead point to SP 800-224
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-224.ipd.pdf

One reason to always use the block size is to avoid Equivalent Keys, see Section 6.2 of SP 800-224. Trivial Equivalent Keys is not a property good MAC/PRF/KDF should have. I would recommend keeping the block size as the default. Entropy wise all the keys are way bigger than they have to be anyway.

HMAC using SHA-3 is somewhat overkill so I don't think there's really any reason to use it over KMAC or even just plain SHA-3, but that being said it's also not insecure so I also don't see a strong reason to disallow it entirely.

Fully agree, HMAC, HKDF, MGF, etc. are construction only needed when the hash function has significant vulnerabilities/issues such as length-extension, failure to behave like a random function, lack of variable length output etc. A reason not to use HMAC for SHA-3 is that it decreases performance and introduces Equivalent Keys.