Re: Serious design flaw in STARTLS documents

At 05:48 PM 4/20/98 -0700, John Myers wrote:
>The protocols as specified are likely to lead to client implementations
>vulnerable to a man-in-the-middle attack directed at
>capabilities/service-extensions OTHER than the STARTTLS extension
>itself.  This occurs if a client believes extensions it received before
>starting up TLS.

To be clear about this: there is no new MITM attack caused by the STARTTLS
extension. It is the fact that a lazy client might assume that the pre-TLS
extensions were covered by the TLS connection, which is clearly wrong.

>The fix is to require that the client discard all knowledge of
>capabilities/extensions it received prior to negotiating TLS.

I think requiring this is overkill. Discussing it in the drafts and saying
that the client MAY ask for the capabilities again is sufficient in my
mind. Specifically, if none of the other extensions announced are
security-related, forcing a new EHLO is wasteful. Note that SMTP and
SMTPbis already explicitly allow sending EHLO again, although some servers
do not allow this (ahem).

>The documents could save a round trip by stating that following a TLS
>negotiation, the server must immediately send a list of
>capabilities/extensions to the client.

This breaks the client-server model of SMTP, so I don't want to put it in
the SMTP/TLS draft. We're not that concerned with one round-trip in SMTP.

>This fix would also address the interoperability problem, which is that
>the list of available SASL mechanisms is likely to depend on the state
>of the TLS negotiation.

Quite right, and possibly worth a mention in the SMTP/TLS draft.

I believe that SMTP/TLS was meant to have been balloted in the IESG by now.
On the other hand, even if it passed, it will be stalled at least a few
weeks waiting for PKIX part 1. Is this change (adding a MAY for uncautious
implementors) important enough to force another IESG last call? I'm open to
input from the list here.

--Paul Hoffman, Director
--Internet Mail Consortium