Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

net/smtp: deprecate CRAMMD5Auth #61952

Open
Neustradamus opened this issue Aug 11, 2023 · 6 comments
Open

net/smtp: deprecate CRAMMD5Auth #61952

Neustradamus opened this issue Aug 11, 2023 · 6 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@Neustradamus
Copy link

Dear @golang team,

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

It is unsecure:

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

Latest IMAP RFC speaks about:

Thanks in advance.

@seankhliao seankhliao changed the title Remove historic CRAM-MD5 mechanism net/SMTP: deprecate CRAMMD5Auth Aug 11, 2023
@seankhliao seankhliao changed the title net/SMTP: deprecate CRAMMD5Auth net/smtp: deprecate CRAMMD5Auth Aug 11, 2023
@seankhliao
Copy link
Member

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

@mknyszek mknyszek added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Aug 11, 2023
@mknyszek mknyszek added this to the Backlog milestone Aug 11, 2023
@drakkan
Copy link
Member

drakkan commented Aug 29, 2023

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
Copy link
Author

@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:

@drakkan
Copy link
Member

drakkan commented Aug 30, 2023

@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:

@Neustradamus
Copy link
Author

@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:

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):

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

Little details, to know easily:

  • tls-unique for TLS =< 1.2
  • tls-exporter for TLS = 1.3

@drakkan
Copy link
Member

drakkan commented Oct 1, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants