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

[Eric Rescorla <[e-mail]>]

On Wed, Mar 9, 2011 at 6:06 AM, Martin Rex <[e-mail]> wrote:
> 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.

In that case, you'll be glad to know it's not a hard limit:

http://tools.ietf.org/html/rfc5246#section-7.4.9

      In previous versions of TLS, the verify_data was always 12 octets
      long.  In the current version of TLS, it depends on the cipher
      suite.  Any cipher suite which does not explicitly specify
      verify_data_length has a verify_data_length equal to 12.  This
      includes all existing cipher suites.  Note that this
      representation has the same encoding as with previous versions.
      Future cipher suites MAY specify other lengths but such length
      MUST be at least 12 bytes.

> 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.

Well, as I've said during this thread, I believe your understanding of what
"security level" means in this context is wrong. I.e., a 128-bit security
level against offline attack is very different than a 2^{-128} chance of
successful guessing exactly once on each connection. However, TLS 1.2
does in fact have the flexibility you are requesting.


> 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.

Oddly, I think of this balance argument as not much more than academic purity.

-Ekr