--On Tuesday, August 12, 2008 09:54:55 PM +0200 Frank Ellermann <nobody@xxxxxxxxxxxxxxxxx> wrote:
Kurt Zeilenga wrote: [TLS]That places restrictions on specifications, not implementations, which is somewhat weird, but CRAM-MD5 could do the same. That is what I propose to do.I personally think such a change would be good. I feel that TLS recommendations to protect CRAM-MD5 ought to be the same as those we made for the TLS protection of PLAIN.Could work. What about existing protocols, has this to be limited to future specifications ? Normally we say "SHOULD" when we mean "old stuff has a good excuse, its old". IIRC there are a two old protocols with a mandatory CRAM-MD5, one of them (on demand relay) won't be updated anytime soon, if ever.
No, we say SHOULD when we mean "do this, unless you think you have a pretty good reason not to". Occasionally we say SHOULD when we mean MUST but want implementations written prior to the specification that don't meet the requirement to be able to claim they are compliant with the spec. Generally this is a poor idea, because it also allows implementations written _after_ the specification to claim they are compliant. In other situations we say SHOULD when we mean "MUST, but we know that some implementations will sometimes behave differently in order to interoperate with old stuff, which is a good reason". In those cases, the goal is not to make the old stuff compliant, but to make it so new stuff can be compliant while still interoperating with the old stuff.
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.
Incidentally, my recollection is that this is exactly the sort of situation that arose with making CRAM-MD5 "limited use". We chose that designation because it was felt that the method should be avoided in new protocols in favor of whatever new thing we end up with, but there were some existing protocols that mandated it. Again, "limited use" does not mean "not deployed" or "no one uses this"; it means "we don't think new uses of this are a good idea", along the same lines as a RFC2119 SHOULD NOT.
It works fine because of PLAIN's design. The party, the server, is preparing both the presented and stored strings. In CRAM-MD5, two parties need to agree on the preparation on what preparation to use for things to work properly.I don't get this point. A new user creating an account picks a free userid, and a password. The details can vary, one way is online in a Web form. If the server can note these credentials for PLAIN, it can also note it for CRAM-MD5 or other mechanisms, in any required format(s), even the somewhat odd "APR1" format. In what way is the design of PLAIN different ? Like CRAM-MD5 it sends the userid as plain text.
PLAIN also sends the password as plain text. CRAM-MD5 does not, so if the client does not encode the password correctly, there is nothing the server can do about it.