Re: some problems with TLS and attacks
Giovanni Pedone <gpedone <at> fub.it>
2003-03-25 08:24:55 GMT
> Why not interpret this as meaning that it must be resumed with
> exactly the same ciphersuite and protocol version as was originally
> negotiated, no changes whatsoever?
> I'm really suspicious of allowing the session to be resumed with
> a different protocol version, in either direction (from TLS to SSL,
> or SSL to TLS). I've never thought carefully about this possibility,
> but it seems possible it might open up a potential for new and subtle
> kinds of attacks. (See Section 4.6 of my paper with Bruce Schneier
> on SSL 3.0.) Does anyone want to devote the brain power to being
> sure that there aren't any such attacks? I'm not excited to do so.
Yes, the simple interpretation is as you said: "same ciphersuite and same
protocol version". :)
Indeed, since che protocol version is somehow included in the ciphersuite
string, I suppose that the TLS specification means that sessions must be
resumed with both same ciphersuite and same protocol version.
This would be easier, maybe, if TLS_RSA_WITH_RC4_128_MD5 (for example) were
considered a different *ciphersuite* from SSL_RSA_WITH_RC4_128_MD5, just
because the protocol version is different, so without the need to specify
"with same protocol version" in the above requirement.
Anyway, the important point is that it is fine not to allow resuming with a
different protocol version (or at least with an older protocol version)
> See Section 4.4 of that paper, in particular the following sentence:
> Now that the pre_master_secret is compromised, it is easy to
> spoof the rest of the key exchange, including forging finished
> messages, to both endpoints.
> The point is that the attacker learns the pre_master_secret secret