mjl-
commented
4 months ago Hi @Neustradamus, thanks for tracking progress on scram support in software. It isn't yet as widely deployed in email as it should. Too many applications use at most cram-md5, or plain. TLS channel binding is rare.
It would be good to understand why scram isn't more commonly supported in servers/clients.
- Perhaps it's not easy enough to find/write/integrate SCRAM (and/or SASL) code? For example, I found a problem with a scram implementation in other software that used a common sasl library, and I think the library API didn't make it easy to do things right.
- Perhaps there are compatibility issues? For example, I've seen client libraries pick the non-PLUS scram variant, while actually doing PLUS during the actual scram exchange, that caused problems.
- Perhaps server applications find it hard to derive new scram secrets for their existing accounts? With email with SMTP and IMAP we have the problem that the server announces which auth methods it implements, but there is no standardized way (e.g. error codes) that indicate derived secrets for some of the mechanisms aren't available for a user (that is trying to login), and which derived secrets actually are available.
As for scram-sha-512 and scram-sha3-512. It's easy to add support. But those are internet drafts. It's not a priority to implement them. I considered already adding code to derive secrets for those mechanisms. It is a very simple change. But there is a risk of implementing drafts that may never make it into an RFC, or will change before being final (e.g. recommended iteration count), and I don't want to create needless legacy code. Once the mechanisms are final and published, I'll implement them.
I've been meaning to do some more real-world testing with email clients and their scram support. FYI, I wrote a simple app to track client/server protocol support some time ago, here is a selection for scram: https://implementations.modernemail.org/#feats=scram. I'm going to test a few clients now and update that matrix. For testing, I'm connecting email clients to https://imapcollect.modernemail.org. It's a proof of concept I created a while ago. It allows anyone to connect, and captures protocol traces (IMAP only for now) and tracks some statistics about connections, including which authentication mechanism was used, but also which extensions were enabled. It would be an option to automatically track protocol support over time for clients (and later servers too) through this mechanism. For now, it makes it clear which auth mechanism a client picks, and clients often identify their version with the IMAP ID command.
Dear @mjl- from Mox team,
After:
Can you add supports of :
You can add too:
"When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802]".
SCRAM-SHA-1(-PLUS): -- https://tools.ietf.org/html/rfc5802 -- https://tools.ietf.org/html/rfc6120
SCRAM-SHA-256(-PLUS): -- https://tools.ietf.org/html/rfc7677 since 2015-11-02 -- https://tools.ietf.org/html/rfc8600 since 2019-06-21: https://mailarchive.ietf.org/arch/msg/ietf-announce/suJMmeMhuAOmGn_PJYgX5Vm8lNA
SCRAM-SHA-512(-PLUS): -- https://tools.ietf.org/html/draft-melnikov-scram-sha-512
SCRAM-SHA3-512(-PLUS): -- https://tools.ietf.org/html/draft-melnikov-scram-sha3-512
SCRAM BIS: Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms: -- https://tools.ietf.org/html/draft-melnikov-scram-bis
https://xmpp.org/extensions/inbox/hash-recommendations.html
-PLUS variants:
IMAP:
LDAP:
HTTP:
2FA:
IANA:
Linked to: