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

<Pasi.Eronen@nokia.com> Fri, 14 September 2007 12:56 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 1IWAjD-00058w-7w; Fri, 14 Sep 2007 08:56:59 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWAjB-00055o-NJ for tls@ietf.org; Fri, 14 Sep 2007 08:56:57 -0400
Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWAjA-0004lT-S2 for tls@ietf.org; Fri, 14 Sep 2007 08:56:57 -0400
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8ECui7R020142; Fri, 14 Sep 2007 15:56:50 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 15:56:44 +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 15:56:44 +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 15:56:43 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2404937802@esebe105.NOE.Nokia.com>
In-Reply-To: <20070914120310.GA29073@tau.invalid>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Issue 49: Finished.verify length
Thread-Index: Acf2x0j8rzjn4yYgQ8qZmqxvoXJpnAABuc1Q
References: <20070914090853.GA20702@tau.invalid> <B356D8F434D20B40A8CEDAEC305A1F2404937712@esebe105.NOE.Nokia.com> <20070914120310.GA29073@tau.invalid>
From: Pasi.Eronen@nokia.com
To: bmoeller@acm.org
X-OriginalArrivalTime: 14 Sep 2007 12:56:44.0394 (UTC) FILETIME=[B3D22CA0:01C7F6CE]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
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:

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

The PRF depends on the ciphersuite, so having the verify_data length
depend on the PRF (or in other words: specifying the verify_data
length at the same place as the PRF) would be one relative simple
approach. 

(But we could allow different ciphersuites using the same PRF
to use different verify_data lengths as well)

Best regards,
Pasi

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