Re: [TLS] Issue 49: Finished.verify length

On Thu, Sep 13, 2007 at 09:07:40PM -0700, Eric Rescorla wrote:
> At Thu, 13 Sep 2007 17:18:39 -0700,

>>>   Currently Finished.verify_data is always 12 octets. With newer PRFs
>>>   and hashes, more might be useful. Should this depend on the PRF?

>> Since the Finished message is just the output of the PRF itself,
>> you can specify however much output you want.  In TLS 1.2, the
>> default PRF is based on HMAC-SHA-256, so 1 iteration of the PRF
>> generates 32 bytes.  With the Finished message currently using
>> only 12 bytes of PRF output, we are just throwing away 20 bytes
>> that could be utilized.  Therefore, the Finished message could
>> be increased to 32 bytes without impacting performance.

Note quite true: Indeed, the additional plaintext of the Finished
message would be there at little cost -- however, this would also give
you more data to encrypt and decrypt at the record layer (e.g., more
cipher blocks, assuming a block size of 16 bytes or less).

> As I recall, the truncation was intended to *increase* security,
> because it leaked less information about the MS to an active
> attacker.

I am not convinced that this is a good reason.  Assume that the
adversary tricks the parties into using weak encryption with some
non-ephemeral key exchange, say.  Then not only the verify_data will
be potentially visible to the adversary, but also the record-layer MAC
will be exposed, which can be a lot of additional data (both depending
on the master secret).

But you don't need a very long verify_data.  We also don't need very
long record-layer MACs.  Both are needed only for real-time
authentication, which cannot be attacked after the fact.  (This
is quite different from symmetric encryption, where we generally want
rather long keys for long-term security.)  The MAC cryptographically
ensures that the data has been sent by someone who knows the keys that
the client and the server have agreed upon.  The verify_data is needed
to check that no-one has disturbed the handshake agreement between
client and server, such as by modifiying the list of ciphersuites
offered by the client.  Here we are already trusting that at least the
MAC is secure, and has been properly keyed.

A 12-byte verify_data means that, if an adversary *has* changed the
handshake, there's a probability around 2^-96 that the server won't
notice this from the client's Finished message.  Thus if you have a
total of 2^64 connections (say) being attacked, then there's a
probabilty around 2^-32 that one of the attacks is not detected by the
server.  But if this ever happens and a connection under attack is
accepted by the server, then still we can expect the *client* to
reject the *server's* Finished message (except with probability around
2^-96).

In conclusion, a 12-byte verify_data means *192-bit* security in total
(2*12*8) for Finished verification, since Finished verification
happens twice!  Thus, I don't see a need to change the specification
in this regard.

Bodo

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls