Re: Do we need IMAP/TLS or POP/TLS?

> From: Keith Moore <[email protected]>
> To: "Paul E. Hoffman" <[email protected]>
> 
> > However, in retrospect, it occurs to me that we might have good reason to
> > leave IMAP and POP over TLS on a separate port. The main reason we want a
> > single port for SMTP and LDAP is because clients do not necessarily have a
> > previous relationship with the servers, and thus won't know whether or not
> > to try the TLS port first if they want to do TLS.
> 
> There's another reason for using only one port: it makes it much
> easier to configure the clients if they can automagically determine
> when TLS is available.  And it's much easier to secure existing
> applications protocols if new "TLS aware" clients can use the same
> configuration (host, port#, etc.) as the old "pre-TLS" clients.
> 
> And no matter what the service, the "try the TLS port first and fall
> back to another port" is trivially vulernable to denial-of-service
> attacks on the TLS port.
> 
> The separate port idea has always been a botch and must be fixed ASAP.
> I've already asked IANA to consult with the APPS ADs before defining
> any more "FOO+TLS" ports for applications.

Bravo!!

> My highest priority as APPS AD is to fix as many existing apps as
> possible, to negotiate TLS in-band.
> 
> Keith


I cc'd ietf-tls because the separate port thread has been discussed there
since the dawn of tls, and this is not just an apps issue.  I suggest that
the discussion continue only on ietf-tls, to avoid spamming both lists.

The three alternatives, in order of increasing "goodness", are:

1) duplicate FOO+TLS ports
2) individual application negotiation
3) session layer negotiation


The SASL document describes the difficulties in negotiating TLS protection
from the application. It's obvious that requiring every application
protocol specification to define an explicit TLS mode is not optimal
either.  And involving application developers in the normal-mode/TLS-mode
negotiation and switching process is guaranteed to introduce security
holes -- this was the reason for defining separate ports in the first
place.

I believe that the most appropriate long-term architecture is to set
the session security protocol in the same manner as the rest of the
network stack:

Just as PPP has a "next protocol" field to specify the network layer
protocol (IP, IPX, ...), and IP has a next field to specify the
transport layer protocol (TCP, UDP, ...), TCP should have a "next"
parameter to specify the session layer protocol.

I propose that a one-byte TCP option be defined which specifies the
next higher protocol.  If the option is absent or has the value 0,
TCP would operate as it does now, without a session layer protocol.
The option value 1 would specify TLS, and the values 2-255 (or 2-240, to
allow a private/experimental protocol space) would be reserved to IANA.

This mechanism would allow applications to simply use setsockopt/getsockopt
to allow or force the use of TLS for a particular connection, instead of
requiring each application to parse application-specific "STARTTLS"-type
commands.  It avoids requiring the application to either:

 * close the existing normal TCP connection and open a TLS connection, or
 * synchronize the start of TLS handshake over an existing TCP connection.

And it doesn't require significant kernel or network stack mods, it only
requires that the application be able to get/set TCP options through
the socket interface.  (This may already be possible in some OSs, but at
least in Solaris, the documentation says "Options may exist at multiple
protocol levels" but it doesn't define any option names for manipulating
IP or TCP options).

The TCP-option method would also allow different types of implementations
to interoperate - one containing the TLS code as part of the network stack
and the other linking TLS into the application.  The separate-port method
already allows this, but the application-negotiation method could not be
built into a TLS network stack.

Although the duplicate-port and application-negotiation methods are the
only available options today, I believe it would be a better use of IETF
resources to define and encourage the implementation of a TLS TCP option,
than to embark on a campaign to modify every application protocol to
enable/negotiate the use of TLS.

The ietf-apps-tls effort is clearly needed as a short term solution, but
we should also be designing long term solutions, not just fighting fires.