net/smtp: deprecate CRAMMD5Auth

[Neustradamus]

Dear @golang team,

Can you remove old unsecure CRAM-MD5 from the code?

• https://github.com/search?q=repo%3Agolang%2Fgo+cram-md5&type=code

It is unsecure:

• https://tools.ietf.org/html/draft-ietf-sasl-crammd5-to-historic-00
• https://tools.ietf.org/html/draft-zeilenga-luis140219-crammd5-to-historic-00

Time to add SCRAM-SHA-*(-PLUS) supports.

Latest IMAP RFC speaks about:

• https://tools.ietf.org/html/rfc9051

Thanks in advance.

[seankhliao]

We cannot remove it as that would be a break in backwards compatibility
maybe we can mark it deprecated
@golang/security @bradfitz

[drakkan]

Hello, I have a WIP patch to add SCRAM-SHA-256 support. I tested it against Postfix with SMTP AUTH through Dovecot SASL.

The SCRAM algorithm requires pbkdf2 and according to RFC 5802 section 5.1 we have to apply the SASLprep profile [RFC4013] of the "stringprep" algorithm [RFC3454]. Since RFC 8265 obsoletes RFC 4013 I think we can use it instead. RFC 8265 is already implemented in golang.org/x/text/secure/precis.

So we need the following dependencies:

• golang.org/x/crypto
• golang.org/x/text

are they acceptable for net/smtp ?

[Neustradamus]

@drakkan: Nice :)

It is possible to support SCRAM-SHA-1/SCRAM-SHA-1-PLUS, SCRAM-SHA-256/SCRAM-SHA-256-PLUS, SCRAM-SHA-512/SCRAM-SHA-512-PLUS, SCRAM-SHA3-512/SCRAM-SHA3-512-PLUS?
Not only 256.

For examples (more at the next link):

• Exim uses GNU SASL and support TLS Channel Binding
• Cyrus-SASL has more supports than Postfix/Dovecot

All details here:

• State of Play scram-sasl/info#1

[drakkan]

@drakkan: Nice :)

It is possible to support SCRAM-SHA-1/SCRAM-SHA-1-PLUS, SCRAM-SHA-256/SCRAM-SHA-256-PLUS, SCRAM-SHA-512/SCRAM-SHA-512-PLUS, SCRAM-SHA3-512/SCRAM-SHA3-512-PLUS? Not only 256.

I haven't looked at channel binding for the PLUS variants yet. The other variants can be added easily but I'm a little worried about SHA-1, nowadays it's not considered secure anymore.

Before completing this work and submitting a CL, I would like to get feedback on the x/crypto and x/text dependencies from the net/smtp maintainers. I would like to avoid working on something that can't be merged

For examples (more at the next link):

• Exim uses GNU SASL and support TLS Channel Binding
• Cyrus-SASL has more supports than Postfix/Dovecot

All details here:

• State of Play scram-sasl/info#1

[Neustradamus]

@drakkan: Thanks for your reply!

For example, SCRAM-SHA-1 and SCRAM-SHA-1-PLUS are used by default since a very long time by XMPP, you can see here:

• https://datatracker.ietf.org/doc/html/rfc6120 (March 2011)

To have a real compatibility with all products, it is needed to support SCRAM-SHA-*(-PLUS) included SHA-1.
Of course, it is better to use SCRAM-SHA-1 than CRAM-MD5/DIGEST-MD5/LOGIN/PLAIN.

Some products which support SCRAM-SHA-*(-PLUS) and SCRAM-SHA3-512(-PLUS):

• State of Play scram-sasl/info#1

About Channel Bindings -> RFC 9266: Channel Bindings for TLS 1.3:

• https://datatracker.ietf.org/doc/html/rfc9266

Little details, to know easily:

• tls-unique for TLS =< 1.2 (RFC5929)
• tls-server-end-point =< 1.2 + 1.3 (RFC5929)
• tls-exporter for TLS = 1.3 (RFC9266)

[drakkan]

Just a quick update on SCRAM support. From the net/smtp docs:

The smtp package is frozen and is not accepting new features. Some external packages provide more functionality.

So it is unlikely this feature will be implemented in net/smtp, however @wneessen is about to complete my WIP, see here

[Neustradamus]

For your information, the recent Dovecot 2.4.0 has SCRAM-SHA-1-PLUS/SCRAM-SHA-256-PLUS supports in more SCRAM-SHA-1/SCRAM-SHA-256.

[CompuRoot]

So it is unlikely this feature will be implemented in net/smtp

Why it should belong to net/smtp if authentication mostly handled by SASL via Cyrus or Dovecot which aren't SMTP but IMAP? Shouldn't it belong to crypto/auth instead since authentication can be used on any network related services, not only SMTP/IMAP?

[xnox]

CRAMMD5Auth if not referenced by the code, does not get compiled into the applications. So in this sense it is mostly harmless for it to still exist.