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 <[email protected]> http://dotat.at/ GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.
