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

[Chris Newman <[e-mail]>]

I am absolutely opposed to the change the IESG has proposed because it will 
result in inadequate real-world security for the IMAP protocol.

RFC 2060 currently requires no security for IMAP.  So the unencrypted 
plaintext password mechanism is the only one that all IMAP products 
implement.  Customers purchasing IMAP software require interoperability and 
thus require support for unencrypted plaintext passwords.  The only upside 
is that SSL/TLS has deployed quite well.

The "SHOULD NOT" language greatly improves the situation because many 
vendors will comply with the spec and advertise that fact, and thus it will 
create market pressure for IMAP vendors to implement STARTTLS.

The "MUST NOT" language is not nearly as effective.  Because vendors can 
not comply with the new spec and meet customer requirements, they will 
ignore the spec and simply claim compliance with RFC 2060.  As a result, 
there will be no new market pressure to improve the status quo.

Therefore, the current "SHOULD NOT" language will provide better real-world 
security than the proposed "MUST NOT" language.

Mark's proposed compromise language is also acceptable and better than the 
current language.

                - Chris

begin  quotation by [e-mail] on 2002/9/19 10:34 -0700:

>
> The IESG had this on the agenda today. The various document nits seem to
> have been satisfactorily addressed. The IESG is also happy with the
> general way the big item in the previous feedback -- mandatory to
> implement security -- has been dealt with.
>
> One concern remains, however. The following note appears in 6.2.1:
>
> Note: a server implementation SHOULD NOT permit any
>       plaintext password mechanisms unless the STARTTLS
>       command described in [IMAP-TLS] has been negotiated.
>       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 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?
>
> 				Ned
>