Russ Allbery wrote:
Hector Santos <hsantos(_at_)santronics(_dot_)com> writes:
Alexey Melnikov wrote:
I would like suggest an alternative: how about saying
The server MUST NOT trust any information obtained from the client,
such as command verbs and their arguments, prior to the TLS
negotiation. The client MUST NOT trust any information obtained from
the server, such as the list of SMTP service extensions, prior to the
TLS negotiation.
This avoid the whole issue of what the client/server must and must not
remember.
I don't follow the client MUST NOT trust statement. Is it not suppose to
believe what the server presents for extensions?
S: We supports STARTTLS, AUTH CRAM-MD5
C: Liar!! No you don't, I don't believe you.
??
It's not supposed to trust what the server said before STARTTLS, since
everything sent before STARTTLS may have been provided by a
man-in-the-middle attacker. It's stronger than just not assuming that the
same extensions apply. Even if extensions happen to still be available,
trusting the extension return before STARTTLS can permit an attacker to
launch a down-negotiation attack, for example.
Maybe I don't see it. If the client is being fooled, one would think
that it would be to relax the client, not push it into a more secured
mode.
In either case, the client has to use what is presented. It can't
assume anything else (that wasn't presented). That was my main point.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com