Re: Further IESG feedback on draft-crispin-imapv-17.txt

[Steve Hole <[e-mail]>]

On Thu, 19 Sep 2002 10:34:10 -0700 (PDT) [e-mail] wrote:

> The IESG would like to push back even harder on the use of plain text
> passwords, and would like to see this changed to read:
> 
> Note: a server implementation MUST NOT permit any
>       plaintext password mechanisms unless the STARTTLS
>       command described in [IMAP-TLS] has been negotiated or some 
>       other mechanism that protects the session from password
>       snooping has been provided. Client and server implementations
>       SHOULD implement additional SASL mechanisms which do not use
>       plaintext passwords, such the GSSAPI mechanism described in
>       [SASL] and/or the [DIGEST-MD5] mechanism.
> 
> The reason the IESG would like to see this change made  should be obvious, but
> in case it is not: The IESG wants to mandate the use of mechanisms that insure
> password snooping isn't possible but recognizes that there are many ways to do
> this besides TLS: SSH, VPNs, physical network security, etc.
> 
> How do people feel about making this change?

Well, I think that it is a good idea in theory, but simply not practical 
at this point in time.   By making this change you will force all 
existing implementations into instant non-compliance, which means that 
they will simply continue to reference rfc2060 rather than the new RFC.

It's a difficult thing isn't it.   The problem is the weight of the 
formerly mandatory to implement LOGIN command and the pervasive use of 
LOGIN in all products.  As is usually the case, the servers aren't the 
problem here, it is the deployed base of clients.   I don't think there is
any practical way of forcing an IMAP server to turn off LOGIN in any kind 
of open environment (University for example).  The best servers will be 
able to do is to provide an "enforce no clear passwords" configuration 
switch that they can enable in the presence of a known set of compliant 
clients (closed enterprise).   The SHOULD wording supports that kind of 
evolutionary deployment model.

I would stay with the SHOULD wording for now.

Cheers.
---
Steve Hole
Chief Technology Officer - Billing and Payment Systems
ACI Worldwide
<mailto:[e-mail]>
Phone: [phone]