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

<Pasi.Eronen@nokia.com> Fri, 14 September 2007 11:40 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW9XG-0005gL-Ls; Fri, 14 Sep 2007 07:40:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IW9XF-0005dx-Az for tls@ietf.org; Fri, 14 Sep 2007 07:40:33 -0400
Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IW9XD-0002VG-Ru for tls@ietf.org; Fri, 14 Sep 2007 07:40:33 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8EBdeOL012620; Fri, 14 Sep 2007 14:40:26 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 14:40:12 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 14:40:12 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Issue 49: Finished.verify length
Date: Fri, 14 Sep 2007 14:40:11 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2404937712@esebe105.NOE.Nokia.com>
In-Reply-To: <20070914090853.GA20702@tau.invalid>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Issue 49: Finished.verify length
Thread-Index: Acf2rvJYY0q1z1kYSP6JGLCGhoYdvAAFC7DQ
References: <20070913183453.D32DD33C21@delta.rtfm.com><46E9D35F.60904@pobox.com><20070914040741.3473733C3A@delta.rtfm.com> <20070914090853.GA20702@tau.invalid>
From: Pasi.Eronen@nokia.com
To: bmoeller@acm.org, ekr@networkresonance.com
X-OriginalArrivalTime: 14 Sep 2007 11:40:12.0797 (UTC) FILETIME=[030412D0:01C7F6C4]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

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

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

Best regards,
Pasi

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