Re: Security

["Frank Ellermann" <nobody@xxxxxxxxxxxxxxxxx>]

Jeffrey Hutzelman wrote:

> In this case, the requirement applies to protocol specifications,
> not implementations.  It's unnecessary to say SHOULD instead of
> MUST in this case, because doing so is not going to have any effect
> on existing published protocols, but may have the wrong effect on
> new protocols.

Makes sense.  OTOH you can't have a "MUST TLS" for ESMTPA, because
the definition of ESMTPA (as opposed to ESMTPSA) is "no TLS".  

The ESMTPA classification is no "protocol", but CRAM-MD5 is.  And
CRAM-MD5 is *the* most popular instance of this class in practice.

A SHOULD with enumerated "good excuses" could cover this situation.
Or a MUST with enumerated exceptions (at most five exceptions).

> Incidentally, my recollection is that this is exactly the sort
> of situation that arose with making CRAM-MD5 "limited use".

Based on Simon's PLAIN vs. CRAM-MD5 comparison table, and still
confident that one i18n "question mark" can be resolved. e.g. as
proposed by Kurt, this "limited use" misses far too many points.

I'd prefer CRAM-MD5 over TLS instead of PLAIN over TLS.  And in
legacy scenarios I prefer CRAM-MD5 over USER:PASS, DIGEST-MD5,
and APOP.

Admittedly "at most five exceptions" would be limited, but does
not cover CRAM-MD5 over TLS.  If you look at the SASL registry
you see that DIGEST-MD5 is listed as "common", ditto OTP.  There
is no plausible reason for this difference.

> it was felt that the method should be avoided in new protocols
> in favor of whatever new thing we end up with

Well, you certainly got the message that I consider it as FUD,
like some statements in DIGEST-MD5 how much better this is in
comparison with CRAM-MD5.  Folks saying so in blogs, or on a
list, outside of RFCs and IANA registries, is okay.  But in an
RFC and IANA registries I prefer technically justified facts.

Clearly DIGEST-MD5 does have features not offered by CRAM-MD5.
Clearly some of them aren't used or have bad interoperability
issues (the MD5sess mess).  Ignoring all that, there just is
no cnonce in CRAM-MD5, and no rspauth.  OTOH it is simple and
easy to implement, let implementors pick what they really need.

> it means "we don't think new uses of this are a good idea"

But that's a highly controversial statement.  From your POV it
is correct, from my POV it is still "when are we ready to get
rid of USER:PASS and APOP ?"  My enthusiasm for advanced stuff
that I've never implemented is also limited, especially if it
claims to offer "security" or "privacy" as defined and sold by
[insert some company you don't like].

 Frank