Hi Sam,
Thanks for looking into this.
According to RFC5802

4. SCRAM Mechanism Names

A SCRAM mechanism name is a string "SCRAM-" followed by the
uppercased name of the underlying hash function taken from the IANA
"Hash Function Textual Names" registry (see http://www.iana.org),
optionally followed by the suffix "-PLUS" (see below).

So the mechanisms are perfectly fine from this perspective. I always wondered why RFC7677 even exists but I do agree that that particular RFC puts additional restrictions on name usage by setting up a registry and mandating only registered mechanisms to be used.

As for 'does not add any security' - this is arguable, sha512 has better collision resistance (even though there's no known practical algorithm to produce collision for either sha256 or sha512 and they are used for HMAC) and higher complexity (means with same iteration count pbkdf2 is more resistant to brute force with 512) - which is handy for securing passwords at rest (salted).

Finally for "no one uses it" - it is defined in Cyrus SASL hence any server/client using that library is potentially using those mechanisms. I've also found references to it in WildFly Security SCRAM SASL Implementation. So I'm afraid it's a bit late to ban its existence.

This does not define those mechanisms or allow arbitrary hashes, it just defines a template for naming new mechanisms.

It does define mechanisms [family] and specifies how they should be named and which registry they should use. But yes it also has the same clause in section 10

Note to future SCRAM-mechanism designers: each new SCRAM-SASL
mechanism MUST be explicitly registered with IANA and MUST comply
with SCRAM-mechanism naming convention defined in Section 4 of this
document.

so I agree that using non-registered names may potentially lead to poor interoperability.

This is not true. SCRAM passwords are not hashed with the hash, it's just used in an hmac. Collisions wouldn't matter, only preimage attacks (of which there are no known ones even for SHA1).

They are using PBKDF2 with HMAC as PRF to be precise. Which protects against collision but not against brute-force. The only protection against brute-force for static string is computational complexity. For PBKDF2 computational complexity is On where O is HMAC complexity and n is iterations. So computational complexity of SHA512 HMAC is higher than that of SHA256 hence it is more resistant to brute-force. 512b hash also requires slightly more memory to compute which is another step up in computing resources requirements.

I'll follow up with them too, but those also support standard mechanisms and no serious service uses it, so the point is that it's not adding any compatibility and could cause harm later.

Thanks, I do understand your drive and I will remove the implementation (from default build, will be enabled by explicit build option)

Thanks, I do understand your drive and I will remove the implementation (from default build, will be enabled by explicit build option)

Thank you, I appreciate this.

SCRAM-SHA3-512(-PLUS):

• https://tools.ietf.org/html/draft-melnikov-scram-sha3-512

SCRAM-SHA-512(-PLUS):

• https://tools.ietf.org/html/draft-melnikov-scram-sha-512

As I said in your other post, those are I-Ds, not accepted RFCs. If they are accepted one day, we should use them then, but only in their final form after they have had expert review. I hope that they will be accepted one day, but we don't know what they'll look like when they are or if expert review will turn up other problems before then.

@SamWhited: It will be validated soon :)
A good job from @aamelnikov.
In several RFCs, there are some links to draft before RFC.