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

[Bodo Moeller <bmoeller at acm.org>]

On Fri, Sep 14, 2007 at 02:03:10PM +0200, 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.)

Oops, I forgot to make explicit what follows from this --:

While longer MACs makes sense for protocols such as IPsec and DTLS,
this doesn't mean that we have a similar reason to use longer
verify_data fields with DTLS.

Bodo


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