[Imap-uw] sasl secuity-layer support

[Mark Crispin]

Hi Mark, comments interspersed below.

On Mon, 6 Feb 2006, Mark Sirota wrote:
> However, I
> think most server administrators would choose SASL security layers over
> TLS/SSL, if given the choice  -- no certificates to manage (including
> things like the revocation problem), and better performance at scale.

I don't understand how this can be an either/or.  TLS/SSL seems to be a 
given for the foreseeable future.  Thus, the question is whether or not 
SASL security layers should also exist as an "and".

The benefits to SASL security layers (at least that I am aware of) are:
  . possible savings of an RTT
  . savings of SSL/TLS key generation overhead on the server.

The disadvantages that I see are:
  . greater complexity -- more security-critical code (and worse, code that
    is not often tested/exercised)
  . limited client implementation (chicken & egg problem)
  . limited overall deployment.  DIGEST-MD5 has real problems, and Kerberos
    remains uncommon.  Very few people use the Kerberos code now.

> I don't buy into the argument that server administrators should be forced
> to accept the worst case.  We can begrudgingly accept the worst case, and
> work to minimize its occurrence.

Why do you feel that SSL/TLS for session integrity, and Kerberos for 
authentication, is a "worst case"?

My intent isn't to be argumentative; I'd really like to be convinced 
because my own arguments in favor of doing SASL security layers failed to 
convince me.

> In addition, we try to take a long-term view and stay on the high road
> when it comes to doing things The Right Way.  Call me old school (I've
> been doing this Internet e-mail thing for 21 years), but for me and my
> organization this has actual value.

I've been doing this Internet e-mail thing from back when it was ARPAnet 
(before Internet).  32 years, as I calculate it.  So I guess that I'm old 
school.

I'd like to hear a convincing argument why it's important to bundle 
session integrity with authentication, and why this is better than using 
SSL/TLS for session integrity and Kerberos etc. for authentication.  Note 
that SSL/TLS has client certificates (& the EXTERNAL SASL authenticator), 
but that doesn't seem to have progressed very far either.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.