On Fri, 31 May 2002, Chris Newman wrote: > > I therefore recommend to the group that we declare that: > > . *the* solution is TLS+AUTH=PLAIN > > . TLS+AUTH=PLAIN is mandatory to implement on both client and server > > . the problem is solved > > and abandon alternatives. > This is acceptable to me.
How should I go about doing this in the base specification? Should the new base specification absorb the information from RFC 2595 and effectively obsolete 2595 with respect to IMAP? Or is there a reason for 2595 to remain as a separate specification? I'd like to do this sooner, rather than later, and if at all possible get something to the IESG before the I-D cutoff. > > Clients: MUST TLS+AUTH=PLAIN and DIGEST-MD5 > > Servers: MUST TLS+AUTH=PLAIN or DIGEST-MD5 > Don't you have the logic reversed for clients and servers? On servers, > code bloat is simply not an issue so implementing both is a no-brainer. I agree with your observation, but... > Clients: MUST implement TLS+AUTH=PLAIN or DIGEST-MD5 (SHOULD implement both) > Servers: MUST implement TLS+AUTH=PLAIN and DIGEST-MD5 This is the correct way of looking at the problem. The problem is that DIGEST-MD5 creates an impossible mandate for any server which does/can not have a plaintext-equivalent password store. There are both technical *and* administrative/security reasons why a server may not have a plaintext-equivalent password store. I think that, although DIGEST-MD5 certainly should be recommended, it presents problems when mandated. > But my instinct is that with the way technology is advancing, Mark's > simpler proposal will be practical even on low-end handheld devices by the > time this is all rolled out. I agree. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate.
