Consider HMAC-based constructions

[wussler]

Given idealized assumptions, consider SHA2-based HMAC constrution:
HMAC(s, K1 || ... || Kn)

Given the following feedback from Felix

Qualitatively similar results [to Keccak] exist for HMAC [2], saying that H(X) = HMAC(s, X) for fixed s is indifferentiable from a random oracle when assuming an ideal Merkle-Damgard compression function.

https://eprint.iacr.org/2013/382
(e.g., Section 1.3: "Analogously, our positive results about HMAC imply as a special case that HMAC(K, M ), for any fixed constant K, is indifferentiable from a RO.")

[OR13]

Interpreting this issue, is it correct to say that:

this issue can be closed when the draft describes that SHA2 or SHA3 can be used, and gives some reasonable guidance to implementers on choosing one and naming the resulting hybrid suite?

[wussler]

Yes. I'm just not so sure about naming the resulting suite, as we don't mention naming anywhere

[OR13]

Yeah, perhaps naming guidance is a step to far... I was mostly hoping to avoid ambiguity for cases like:

• ML-KEM+X25519+SHA2
• ML-KEM+X25519+SHA3

Pick the hash function that is used internally the most, in case of a tie, pick the hash function that has been battle tested for longer.

Avoid creating suites that only differ by the choice of hash function.