RFC6331: Moving CRAM-MD5, DIGEST-MD5 and LOGIN to Historic

[Neustradamus]

20 November 2008: CRAM-MD5 to Historic:

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

29 June 2017: CRAM-MD5 to Historic:

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

July 2011: RFC6331: Moving DIGEST-MD5 to Historic:

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

I add same about SCRAM-MD5.

There are now:

• July 2010: RFC5802: Salted Challenge Response Authentication Mechanism (SCRAM): SASL and GSS-API Mechanisms: https://tools.ietf.org/html/rfc5802 (SCRAM-SHA-1 and SCRAM-SHA-1-PLUS)
• July 2010: RFC5803: Lightweight Directory Access Protocol (LDAP) Schema for Storing Salted: Challenge Response Authentication Mechanism (SCRAM) Secrets: https://tools.ietf.org/html/rfc5803
• November 2015: RFC7677: SCRAM-SHA-256 and SCRAM-SHA-256-PLUS: Simple Authentication and Security Layer (SASL) Mechanisms: https://tools.ietf.org/html/rfc7677

Soon:

• 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

[jparise]

Is this a request to deprecate (or remove) CRAM-MD5 support?

[schengawegga]

I think we´ve done this with PR #76.
@Neustradamus do you agree with this and we can close this issue successfully?

[schengawegga]

After a little bit of research and a few mails with @Neustradamus, we both agree that the authentication methods CRAM-MD5, DIGEST-MD5, LOGIN and PLAIN are not secure enough to use it in the future. In PR #76, i´ve done a few changes to inform the users about the security issue using this authentication methods.

The question is, what are the next useful steps?

The suggestion of @Neustradamus was, to remove CRAM-MD5, DIGEST-MD5 and LOGIN. Only PLAIN should stay in the Class, because there are Mailservers out there wich only supports PLAIN as authentication method.

I am not sure about that, because i don´t want to make this library useless for some users wich Mailservers do not support more secure authentication methods.

My idea was, to make this authentications methods only useable if a TLS connection is established. Because the credentials were transfered through a more secure connection layer. Than the authentication method should not be a security issue. Or am I wrong in my assumption?

@till @jparise what do you think about that? do you know any security or encryption experts who can give a suggestion about that?

[jparise]

@till @jparise what do you think about that? do you know any security or encryption experts who can give a suggestion about that?

Because this is a client (not server) library, I think it's useful to continue offering support for these methods but also help end users make informed decisions about their security.

[schengawegga]

@till @jparise what do you think about that? do you know any security or encryption experts who can give a suggestion about that?

Because this is a client (not server) library, I think it's useful to continue offering support for these methods but also help end users make informed decisions about their security.

@jparise i agree. What do you think about my suggestion to make them only available with TLS? Do you think this would remove the security gap, using this unsecure methods? I am not a deep security expert. Do you know an security encryption experts?

[jparise]

@till @jparise what do you think about that? do you know any security or encryption experts who can give a suggestion about that?

Because this is a client (not server) library, I think it's useful to continue offering support for these methods but also help end users make informed decisions about their security.

@jparise i agree. What do you think about my suggestion to make them only available with TLS? Do you think this would remove the security gap, using this unsecure methods? I am not a deep security expert. Do you know an security encryption experts?

I think I'd apply the same reasoning: leave them available but caution users not to use them in insecure ways.

I would support removing them entirely in a new major version.

[Neustradamus]

The 1.11.0 release has done an important progress, DIGEST-MD5 is DEPRECATED:

• https://github.com/pear/Net_SMTP/releases/tag/1.11.0

And several SCRAM supports have been added (not -PLUS variants at this time):

• SCRAM-SHA-1(-PLUS) + SCRAM-SHA-256(-PLUS) + SCRAM-SHA-512(-PLUS) supports #57