my writeup for draft-newman-tls-imappop

I've just finished my review of this for IESG.  I'm forwarding
my writeup to this list because I want to gauge reaction for
my suggestion to resolve the dispute over "must not permit
cleartext".  Please note that IESG hasn't discussed the document
yet - I have to do the writeup to get it on IESG's agenda.

please send comments on this to me personally
(you can cc patrik and/or the security ADs if you like)
because I'm more likely to see the comments there.
if you must respond to this list, be civil :) 

Keith


The IESG has approved the Internet-Draft 'Using TLS with IMAP, POP3 and
ACAP' <draft-newman-tls-imappop-08.txt> as a Proposed Standard.  This
has been reviewed in the IETF but is not the product of an IETF Working
Group.  The IESG contact persons are Keith Moore and Patrik F=E4ltstr=F6m.

Technical Summary

This specification defines extensions to IMAP, POP, and ACAP which
activate TLS.  It also defines a simple PLAIN SASL mechanism for
use underneath strong TLS encryption with ACAP or other protocols
which lack a clear-text login command.

This document therefore provides (a) privacy and (b) two additional
authentication methods for use with these protocols:

1. TLS authentication with client certificates
   (if client and server each support the SASL EXTERNAL mechanism)
2. authentication using passwords over an encrypted channel
   (using either the SASL PLAIN mechanism, or the IMAP LOGIN
    command, or the POP USER command)

The latter method allows authentication using existing non-invertable
password databases, without exposing the password to eavesdroppers.

This method of using TLS with these protocols is considered preferable
to the currently deployed method of using a separate port for 'secure'
IMAP or POP.

Working Group Summary

This document was not developed by a working group but has been
discussed on several mailing lists, notably [email protected].
It has mostly been uncontroversial, and except for one point
(to be arbitrated by IESG) there appears to be rough consensus
on the result.

Protocol Quality

The protocol appears to be a sound means of layering TLS on top
of existing protocols, and the document pays adequate attention
to the various implementation and operational issues associated
with doing so.  

Keith Moore reviewed the specification for IESG.

-------------------------------------------------------------------
notes for IESG:

These are my suggested tweaks, but others (esp. the security ADs)
might have other ideas:

1. section 2.2:

I don't see how it helps to insist that clients and servers require 
encryption, without giving the user or administrator some ability
to insist that some minimum strength of encryption be used.  
Yes this is a matter of local policy (though we could make a
recommendation) but implementations have to allow the user
and admin to implement reasonable policy, else we don't interoperate.

One idea for how to fix this is that since we're requiring 
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, clients and servers should 
at the very least have the ability to insist on this ciphersuite.

Ideally, clients and servers would have fairly fine-grained control
e.g. allowing them to enable, disable, or require selected ciphersuites.
(perhaps on a per-user or per-server basis)

2. section 2.3

> Both clients and servers which implement STARTTLS MUST NOT permit
> clear-text login commands or mechanisms unless an encryption layer
> is active or backwards compatibility dictates otherwise.

This language is somewhat controversial.  Part of the problem is that 
plaintext authentication mechanisms - both standards-track and 
nonstandard are already widely deployed and there is a reluctance 
to deprecate them.  Hence the "backward compatibility" clause.  Even
so, several people have objected to the current language, because it
forces them, if they add TLS and want to claim conformance to this 
spec, to break compatibility with the installed base.

I would reword this as:

> Clients and servers which implement STARTTLS MUST be configurable 
> to refuse all clear-text login commands or mechanisms (including 
> both standards-track and nonstandard mechanisms) unless an encryption
> layer of adequate strength is active.

possibly adding

> Servers which allow unencrypted clear-text logins SHOULD be 
> configurable to refuse clear-text logins both for the entire
> server, and on a per-user basis. 

3. section 6.

I wonder about allowing UTF-8 usernames and passwords - because it seems 
likely that different user agents will translate keyboard input to UTF-8
in different ways (if they can't even agree on what to generate 
when backspace and delete and quotes are pressed, how will they 
generate UTF-8 consistently, given combining characters etc.) 
It seems like there needs to be some standardized canonicalization 
step to allow this to work interoperably.

But I'm fairly sure this isn't the first time we've allowed utf-8 in 
usernames and passwords.

Keith