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

[Martin Rex <[e-mail]>]

Eric Rescorla wrote:
> 
> On Martin Rex wrote:
> >
> > 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:

Great, we come around full circle.  Does anyone remember the subject
of the thread -- a TLS cipher spec that defines a PRF with SHA-384.

Yes, I'm aware what TLSv1.2 says.  But I'm much more aware of
the complete lack of guidance (a pointer to rfc-2104 section 5
would have been sufficient).

All I've been asking for, is, that (draft-kanno-tls-camellia-00.txt)
should (re-)define the truncation of the finished messages in case
that SHA-384 is used for the PRF to at least 192 bits (24 octets),
following the recommendation in rfc-2104 section 5 in order to obtain a
sensibly balanced crypto of the desired strength -- or alternatively
provide a convincing rationale why it is _not_ following that
recommendation.

Alternatively, if they favour your attitude that actually
SHA-1 would have been good enough, and SHA-256 is plenty,
they should remove all the -SHA384 ciphersuites from the
document.


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

TLSv1.2 should have used that flexibility itself for a SHA-256 PRF,
and should have provided a pointer to rfc-2104 section 5 for selecting
an adequate truncation size for TLS cipher suite specs that use this
flexibility.

What seems to have happened is that although there are cipher suite
specs that redefine the PRF, they fail to address the truncation
because TLSv1.2 fails to address the truncation ("bad precedent").


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

With respect to the truncation to 96-bits in TLSv1.2 -- yes, it doesn't
seem serious enough to worry.

But the finished messages (the only MACs that are actually truncated in
TLS by default) have been re-used for authentication purposes outside
of TLS in the form of channel bindings.  You may have more than one
attempt to replay a channel-bound authentication token of an
authentication inside TLS _without_ invalidating the TLS session.

The HMACs on the TLS data records are not reused anywhere.  So there
a truncation to no less than half the length of the hash would save
network bandwith without impairing security according to rfc-2104 section 5.
But TLSv1.2 doesn't do that by default.

TLS could have taken more advantage of the normative references that
it has been carrying through since TLSv1.0, I believe.

-Martin