[TLS] Counter structure

Eric Rescorla <ekr@networkresonance.com> Tue, 19 December 2006 21:10 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmEb-00036p-Cw; Tue, 19 Dec 2006 16:10:49 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwmEZ-00036T-Mr for tls@ietf.org; Tue, 19 Dec 2006 16:10:47 -0500
Received: from laser.networkresonance.com ([198.144.196.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GwmEY-0002yd-AF for tls@ietf.org; Tue, 19 Dec 2006 16:10:47 -0500
Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 942575C089; Tue, 19 Dec 2006 13:13:57 -0800 (PST)
To: tls@ietf.org
X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19)
Date: Tue, 19 Dec 2006 13:10:45 -0800
From: Eric Rescorla <ekr@networkresonance.com>
Message-Id: <20061219211357.942575C089@laser.networkresonance.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
Cc: kent@bbn.com
Subject: [TLS] Counter structure
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

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