RE: [TLS] Counter structure
"Blumenthal, Uri" <uri.blumenthal@intel.com> Wed, 20 December 2006 18:14 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx5xe-0006M3-U1; Wed, 20 Dec 2006 13:14:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gx5xd-0006LA-Qe for tls@ietf.org; Wed, 20 Dec 2006 13:14:37 -0500
Received: from mga01.intel.com ([192.55.52.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gx5xc-0004VZ-Es for tls@ietf.org; Wed, 20 Dec 2006 13:14:37 -0500
Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 20 Dec 2006 10:14:36 -0800
Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by fmsmga001.fm.intel.com with ESMTP; 20 Dec 2006 10:14:35 -0800
X-ExtLoop1: 1
X-IronPort-AV: i="4.12,193,1165219200"; d="scan'208"; a="179875043:sNHT23828007"
Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 10:14:20 -0800
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] Counter structure
Date: Wed, 20 Dec 2006 13:14:17 -0500
Message-ID: <279DDDAFA85EC74C9300A0598E704056011D1A28@hdsmsx412.amr.corp.intel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Counter structure
thread-index: AccjsjOj9wdzJnavSEeHLzwywTDj3QAsB/GQ
From: "Blumenthal, Uri" <uri.blumenthal@intel.com>
To: Eric Rescorla <ekr@networkresonance.com>, tls@ietf.org
X-OriginalArrivalTime: 20 Dec 2006 18:14:20.0011 (UTC) FILETIME=[AB2593B0:01C72462]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: kent@bbn.com
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
Considering that computational performance (crypto speed) seems more precious now than the bandwidth - I suggest that paying 8 extra bytes per record for support of hardware parallelization is a good trade-off. I am for it. -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com] Sent: Tuesday, December 19, 2006 4:11 PM To: tls@ietf.org Cc: kent@bbn.com Subject: [TLS] Counter structure Currently, the (D)TLS Counter draft uses the sequence number to generate the per-record IV. Recently, Steve Kent pointed out a drawback of this mode which mau motivate a different counter structure. I was hoping we could discuss this on the list and try to reach consensus. Here's the issue as I understand it (Steve, please correct me if I screw something up): The CTR IV is security critical in a way that the CBC IV is not. Accordingly, for evaluated products the IV must be generated inside the evaluation boundary where it can be insured that it's not reused. As the IV is currently designed, this would mean that the record sequence number was also maintained inside the security boundary. Ordinarily, this isn't an issue but in implementations where you are doing hardware record processing you might have multiple parallel hardware modules. Synchronizing the sequence number between those modules could be quite problematic. An alternate approach is to use an explicit per-record IV which can be maintained independently by each encryption module. This IV doesn't need to be the full block width, just long enough to prevent collisions. If the modules use a counter or LFSR (with a few bits reserved for module ID) to generate the IV, then you can get by with 64 bits of IV. [0] So, the question is: is enabling this kind of parallel hardware implementation a good tradeoff for 8 more bytes of record size? Please discuss. Thanks, -Ekr [0] Note that this IV size more or less precludes random IVs because of birthday statistics. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] Counter structure Eric Rescorla
- RE: [TLS] Counter structure Blumenthal, Uri
- Re: [TLS] Counter structure Russ Housley