Re: [TLS] AES and SSLv3 (was Re: Unfortunate current practices for HTTP

[Marsh Ray <[e-mail]>]

On 01/19/2011 01:07 PM, Martin Rex wrote:
>
> If cipher suites had ever been conceived to be
> protocol-version-specific, they would have partitioned the
> cipher suite code points.
>
> Quite obviously, the cipher suite registry was _NOT_ partitioned
> for TLSv1.0.  cipher suites were issued with no distinction whatsoever,
> so they were clearly meant to apply in a protocol-version-independent
> fashion, forwards and backwards.

+1

We have to keep in mind that SSLv3 is deprecated abandon-ware, but this 
premise "AES ciphers are not valid choices for SSLv3" is wrong.

If the client proposes advertises a range of protocol versions and the 
server picks a value from that range, and if the client proposes a set 
of ciphersuites and the server picks a ciphersuite from that set, then 
interoperability should ensue.

Note the similarity with the servers that fail to handshake with clients 
who propose extensions. "SSLv3 does not allow extensions" was the 
justification given that time. SSL/TLS is an extensible protocol, just 
because some options weren't defined at the time of the core protocol 
version doesn't mean they're invalid to use. The handshake negotiation 
was designed to allow this.

The problem is that the client is in some sort of "fall back to SSLv3" 
heuristic mode. The reason clients are forced to do that is the 
occasional presence of poorly interoperating servers.

The root cause is thus the poorly interoperating servers. They are the 
stratospheric chlorofluorocarbons catalyzing away the ozone. They do 
damage to the ecosystem with a large multiplier effect.

The only solution is to relentlessly pursue interoperability and be 
diligent about providing updates.

- Marsh