On Fri, 30 Jan 2009, Hector Santos wrote:
But I still to get the "Client MUST NOT trust" statement. It has to trust,
blind or otherwise, what the server presented up to this point before it can
go to the next step.
The client can verify when it receives the server certificate that the
connection up to that point was with the correct server. Before TLS is up
and running, anything the client gets from the server must be treated as
provisional, to be verified using data from trustworthy sources.
Many TLS clients are too trusting - they rely on the server capability
list to decide whether to use TLS or not, which opens them to downgrade
attacks. If a client has reason to expect that the server supports TLS
then it should treat the absence of TLS support as an attack. (i.e. the
common MUA configuration option of "TLS when available" does not comply
with this requirement.) This is obviously problematic for inter-domain TLS
to an MX, but TLS to MX is fundamentally broken and needs rethinking.
In my view, I think it should say:
The client MUST NOT presume the server extensions apply
in the secure state as it may have changed.
It already says that in the paragraph that follows my proposed text.
To me, that is enough to give the client the incentive and understanding
that it needs to re-issue EHLO.
Remember this thread was started by someone who wrote code that did not.
Tony.
--
f.anthony.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.