Re: [TLS] Counter structure

[ SECURITY AD HAT OFF ]

We had a very similar discussion when we were trying to figure out 
what structure to use for Counter Mode in the context of IPsec.  The 
possibility of multiple modules was a very real concern in that 
context.  This might be in the future for TLS too.  TLS is used to 
provide hop-by-hop protections for SIP, and it seems to me that a 
media gateway may need enough hardware support for this to be an issue.

I support the use of a few more bits to ensure that support for such 
a capability is straightforward.

Russ

At 04:10 PM 12/19/2006, Eric Rescorla wrote:
>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