Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx

[Martin Rex <[e-mail]>]

Yoav Nir wrote:
> 
> On Mar 9, 2011, at 2:06 PM, Martin Rex wrote:
> 
> > 
> > What I'm reading here is that a truncation of an HMAC or an HMAC-like
> > construct to 96 bits cuts the effective security down to 96-bit.
> > 
> > You call the use of SHA-384 for the HMAC in such a situation "overkill",
> > I call it cryptographic imbalance.
> 
> I've heard the balance argument before, and I don't really find it
> compelling. It implies that if I'm using 1024-bit RSA, then it is
> inherently wrong to use AES-128 or SHA-384. There are other
> considerations in design besides bit-strength. Bit strength should
> be used as a minimum value, depending on the estimated resources
> of your opponent.

There is a big difference whether a limitation is hardwired into a
protocol, or whether a limitation is a side-effect of configuration
and properties selected by the consumer of the technology.

For most TLS implementations that I'm aware of, the cipher suites
are user-configurable and the size of the keys in the server
certificates and the hash that is used in the signature of
the certificates are determined by the consumer.


The truncation of the finished message hashes to 96-bits is an undue
hard limit in TLSv1.2, and it becomes more aggravating if you're
using a hash with an even larger output size than SHA-256 and the
truncation of the finished messages is not changed to be no less
than half the output size of the hash algorithm.


I also prefer AES over 3DES-EDE cipher suites for our TLS implementation,
which is why I made them prefered by default (the server has the privilege
to chose the common cipher suite, though).

TLS implementations of SSLv3, TLSv1.0 and TLSv1.1 that prefer AES256
over AES128 by default are imbalanced, because they're wasting
resources.  


TLSv1.2 was supposed to provide a framework that can deliver TLS
with a strength >128=bits of security.  But it failed to deliver
this by (1) not adjusting the truncation of the finished messages
and (2) not documenting that the truncation of the finished messages
MUST be done along with the use of stronger ciphers, stronger hashes
and larger key lengths in order to actually obtain a balanced
security of the desired higher strength.


If anyone is wondering: No, I'm definitely _not_ looking for a
backwards incompatible change of TLSv1.2.  I didn't want to break
interop with the installed base of SSLv3 when we did TLS extension RI,
and neither do I want to break interop with the installed base of
rfc-5246 now.

Even when facing real non-compliance, like the botched client_version check
on the premaster secret in Windows 7 schannel, I'm more interested
in producing recommendations that avoid interop problems, because
in the IETF interoperability used to be more important than
academic purity in design.


-Martin