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

<Pasi.Eronen@nokia.com> Fri, 14 September 2007 14:29 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 1IWCAM-0002w6-DE; Fri, 14 Sep 2007 10:29:06 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IWCAL-0002tu-2z for tls@ietf.org; Fri, 14 Sep 2007 10:29:05 -0400
Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IWCAK-0000BA-Fo for tls@ietf.org; Fri, 14 Sep 2007 10:29:04 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l8EESiUa000797; Fri, 14 Sep 2007 17:29:00 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 17:28:24 +0300
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Sep 2007 17:28:25 +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 17:28:24 +0300
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2404966D3F@esebe105.NOE.Nokia.com>
In-Reply-To: <20070914141809.2439533C21@delta.rtfm.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Issue 49: Finished.verify length
Thread-Index: Acf22pgrtfelhW9rToKBwV/XDLEbTQAACktA
References: <20070914090853.GA20702@tau.invalid><B356D8F434D20B40A8CEDAEC305A1F2404937712@esebe105.NOE.Nokia.com><20070914120310.GA29073@tau.invalid><B356D8F434D20B40A8CEDAEC305A1F2404937802@esebe105.NOE.Nokia.com> <20070914141809.2439533C21@delta.rtfm.com>
From: Pasi.Eronen@nokia.com
To: ekr@networkresonance.com
X-OriginalArrivalTime: 14 Sep 2007 14:28:25.0085 (UTC) FILETIME=[827D02D0:01C7F6DB]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
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

Eric Rescorla wrote:

> I'm still trying to understand the rationale for why it makes sense
> to have a verify_data != 12 bytes. Pasi, could you elaborate?

Again, I'm not suggesting changing it from 12 bytes; just allowing
the agility to change it in the future without new TLS version.

One (somewhat hypothetical) use would be a cipher suite that tries 
to have _everything_ at 256-bit security level (maybe for some 
government approval reasons; not today, but maybe 5 years from now).

You might argue that this kind of security level isn't really
needed, but then again, some people seem to be willing to go
to great lengths to match these "security levels" (just think
of SHA-224.. :-)

Best regards,
Pasi

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