Re: STARTTLS & EHLO: Errata text?

[[e-mail]]

> On Thu, 29 Jan 2009, Tony Hansen wrote:
> >
> > Section:
> >    4.2 Result of the STARTTLS Command
> >
> > Old text:
> >    The server MUST discard any knowledge obtained from the client, such
> >    as the argument to the EHLO command, which was not obtained from the
> >    TLS negotiation itself.
> >
> > New text:
> >    The server MUST discard any knowledge obtained from the client that
> >    was not obtained from the TLS negotiation itself. The server state
> >    is otherwise as if the connection had just been opened.

> I prefer Alexey's suggested "MUST NOT trust" text.

> Note that my comment about AUTH information applies to the client as well
> as the server.

> Also note that AUTH means this trust issue applies to more than just SMTP
> commands, arguments, and replies - it applies to SASL exchanges as well.

> > Section:
> >    4.2 Result of the STARTTLS Command
> >
> > Old text:
> >    The client SHOULD send an EHLO command as the
> >    first command after a successful TLS negotiation.
> >
> > New text:
> >    The client MUST send either an EHLO command or a HELO command as the
> >    first command after a successful TLS negotiation.

> That's incorrect. It's OK to QUIT at this point, for example. Rather than
> paraphrasing 2821/5321, perhaps it would be better to quote verbatim.

> I suggest that this paragraph should read:

>    Upon completion of the TLS handshake, the SMTP protocol is reset to
>    the initial state (the state in SMTP after a server issues a 220
>    service ready greeting).  The requirement in [RFC5321] that "a client
>    MUST issue HELO or EHLO before starting a mail transaction" also
>    applies to this fresh state.

>    The server MUST NOT trust any knowledge obtained from the client before
>    the TLS negotiation itself.  The client MUST NOT trust any knowledge
>    obtained from the server before the TLS negotiation itself.  This
>    includes all commands, arguments, replies, and extended exchanges
>    (though in typical use there is little more than the client's EHLO
>    command and the server's reply).

This definitely works for me.

> >    Because the server state machine is reset to an initial connection
> >    state after negotiating TLS, and any modifications to the server
> >    state will be lost, the client SHOULD NOT issue any MAIL
> >    FROM or RCPT TO commands prior to using the STARTTLS command.

> I think this is unnecessary. I doubt anyone has been confused enough to
> implement software that would violate this requirement. I only mentioned
> it for sake of argument.

Agreed.

				Ned