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

[Bodo Moeller <bmoeller at acm.org>]

On Fri, Sep 14, 2007 at 02:40:11PM +0300, Pasi.Eronen at nokia.com wrote:
> Bodo Moeller wrote:

>> 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 true; but reasonable people seem to have different opinions 
> on what exactly is "sufficiently long". For example, RFC 4106 specifies
> three different choices for ICV (MAC) length (128/192/256 bits).

IPsec is a different setting since it is not based on streams (which
would be aborted in case of a decryption error).  However, this
reminds me to take DTLS into account, so yes, we possibly might need
long record-layer MACs (just for consistency for DTLS, not for actual
TLS security reasons).

Of course, the Finished message payload (verify_data) still will have
to be processed just once.  (An incorrect record-layer MAC is just a
reason to discard this particular packet in DTLS, but if the
record-layer MAC is correct and the verify_data isn't, then this
is a very bad sign, and the session should be canceled.)


> My suggestion was *not* to increase the current length, but rather 
> to add "agility" for this parameter as well (so that we don't
> need to revisit the TLS base spec if, e.g., some future cipher 
> suite wants to have all the pieces at 256-bit level).

OK, this makes perfect sense!  The question as cited here was,
should the verify_data length depend *on the PRF*.  It shouldn't;
but that doesn't mean we can't allow individual ciphersuites to
specify their preferred verify_data lengths.

Bodo


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