Re: Security

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Sam Hartman <hartmans-ietf@xxxxxxx> writes:

>>>>>> "Simon" == Simon Josefsson <simon@xxxxxxxxxxxxx> writes:
>
>     Simon> Sure, but if CRAM-MD5 is used with TLS, the initial
>     Simon> statement above is misleading: there is nothing in the
>     Simon> security considerations of CRAM-MD5 that explains how
>     Simon> CRAM-MD5 under TLS fails to provide adequate protection.
>
>     >> It is my belief that WG consensus is that the current text is
>     >> adequate in both of these areas.  I encourage anyone who thinks
>     >> the current text can be approved upon offer alternative text
>     >> for the WG to consider.
>
>     Simon> I suspect people read different things into the first
>     Simon> statement here.  I suggest to change it to:
>
>     Simon>   CRAM-MD5 used without TLS is no longer considered to
>     Simon> provide adequate protection.
>
> I don't object to this change.
> I do object to cram-md5 on the standards track.
>
> Kurt commented that recommendations for cram-md5 should be the same
> for plain.  I disagree because since cram-md5 is a challenge/response
> mechanism we can do better than plain.  Plain is the best we can do in
> cases where you need to send a password to the server.
>
> However for challenge/response mechanisms we can get mutual
> authentication and tie the mutual authentication to integrity
> protection and/or confidentiality.  Since cram-md5 does not support
> these capabilities either through security layers or channel binding,
>  I do not think it should be updated on the standards track.
>
> Also, I do believe that cram-md5's mechanisms for converting a
> password into a key are weaker than is current accepted security
> practice.

We disagree on the principal here.  Merely because there are known
vulnerabilities (which can be fixed by using TLS), that shouldn't
prevent something to go on the standards track.  If that were the
metric, we wouldn't publish SMTP on the standards track due to spam
concerns.  You make it sound as if only perfect protocols should be on
the standards track.

Your approach would send the message that we recommend users to prefer
PLAIN+TLS over CRAM-MD5+TLS.

/Simon