draft-ietf-ipsec-ciph-aes-ctr-00.txt

["David A. Mcgrew" <mcgrew@cisco.com>]

Russ,

I have several comments on draft-ietf-ipsec-ciph-aes-ctr-00.txt.  It's
clearly written and I value the effort that you've made to get the
job done and establish some sort of compromise.  However, there are
two points on which the draft can be improved: packet expansion and
strength against precomputation attacks.  In the following, I lay out
some arguments in favor of an implicit (rather than an explicit) IV,
discuss interoperability with other counter mode versions, and mention
some other points.

First, a correction to the Security Section.  In the last paragraph of
Section 6, the draft is right to state that no more than 2^64 blocks
should be encrypted with any fixed key.  But the draft implies that
this limitation can be avoided if implementations "make use of the
longer AES key sizes."  This is not right, the 2^64 limit applies to
all key sizes.  It does not apply to larger block sizes; however, the
AES spec doesn't include the larger RIJDNAEL block sizes.  In the same
vein, the sentence "Additionally, AES with a 128-bit key is vulnerable
to the birthday attack after 2^64 blocks" should read "Additionally,
AES is vulnerable...".

On the subject of packet expansion, the draft requires the use of an
explicit IV that is eight bytes long and states that this overhead is
acceptable.  I disagree.  Counter mode has the opportunity to provide
zero expansion, and at Cisco we've regarded this property as
important.  The consumption of eight bytes per packet can have a
significant impact on bandwidth, especially for protocols with short
packets like voice over IP (RFC 1889).  For example, RTP with the
G.729 codec (as is commonly used) carries only twenty bytes of data
per packet.  This protocol is often used with link-layer header
compression over WAN links (e.g. RFC2508); these compression methods
are quite efficient, making the bandwidth degradation due to
uncompressible fields (like the explicit IV) pronounced.

I think that the zero-expansion property is important enough that I
want to comment on the points that the rationale presents in favor of
an explicit IV:

  Point 4.  "The assignment of the per-packet counter block value
  needs to be inside the assurance boundary.  Some implementations
  assign the sequence number inside the assurance boundary, but others
  do not."  What implementations maintain the ESP sequence number
  outside of the security perimeter?  Cisco does not do this, nor do
  any of the several of crypto hardware suppliers that we use.

  Counter mode ESP would be far simpler and more bandwidth efficient
  if the ESP sequence number were used as the per-packet counter
  value.  In addition, other cryptographic mechanisms that require a
  nonce can use the sequence number for that purpose, if we are
  allowed to assume that the sequence number is actually unique.
  These mechanisms include ciphers like SEAL and Wegman-Carter based
  MACs like MMH.  It's worth noting that we've implemented SEAL
  encryption using ESP, as described in the Stream Cipher ESP; this
  draft is now expired, but went through three revisions without this
  point about the sequence number and assurance boundary being raised.
  (The old draft is online at
  www.mindspring.com/~dmcgrew/draft-mcgrew-ipsec-scesp-02.txt if
  you're interested, and we'd be fine with re-issuing the draft were
  there is interest from other implementers.)


  Point 2.  "Adders are simple and straightforward to implement, but
  due to carries, they do not execute in constant time.  LSFRs offer
  an alternative that executes in constant time."  However, the
  per-block increment operation is far more time critical than the
  per-packet increment operation!  Since the block counter is a
  monotonically increasing integer, and it's presumably fast enough,
  it's hard to see how the fact cited in the draft supports the use of
  LFSRs for the per-packet field.


  Point 1.  "... there is no advantage to selecting a mechanism that
  allows the decryptor to determine whether counter block values
  collide.  Damage from the collision is done, whether the decryptor
  detects it or not."  Yes, but the detection of a malfunctioning ESP
  sender could enable an administrator to shut off the errant device.
  Either the ESP CTR receiver or a passive security monitoring device
  such as a network IDS system can detect ESP sequence number re-use.
  When is the delayed detection of the failure of a security system
  worse than no detection?

I don't disagree with Point 3 and Points 5 and 6 follow from the
others.

I would be surprised if other implementers in the WG favored the use
of an unspecified explicit IV over the use of the sequence number as
an implicit IV.  At any rate, I think we've discussed the points well
enough to allow others in the WG to chime in.


On to other topics.  The draft says in Section 6 that AES CTR MUST NOT
be used with statically configured keys.  I certainly agree that this
is a good thing.  However, RFC2401 requires implementations to support
such keys, saying "This document requires support for both manual and
automatic distribution of keys."  Perhaps that RFC means that manual
keying be provided only for some ciphers (the mandatory to implement
ones?).  At any rate, it would be good for the WG to decide what is
meant and to document it somewhere.  (The Stream Cipher ESP draft hit
this same issue).

On the subject of interoperability, the AES CTR draft could be
implemented using draft-mcgrew-saag-icm-00.txt (the generic counter
mode draft that I wrote last November, which also lines up with the
AES CTR variant in draft-ietf-avt-srtp-05.txt), if the spec were bent
hard enough.  This bending would consist of defining the 'initial
offset' to be equal to (flags, truncated_spi), and of course throwing
the explicit IV in front of the ciphertext.  All of the AES CTR specs
that I've seen have managed to agree that the per-block counter be a
big-endian integer in the least significant bits of the counter, which
probably ensures that implementations can share keystream-generation
components.

OTOH, while the closeness of the various AES CTR specifications is a
good thing, the fact that the initial offset is not random has a
negative security impact.  The WG may decide that it prefers
simplicity to strength against precomputation attacks.  If so, fine,
but this subject needs to be discussed in the rationale.

In Section 6 the draft says:

   "Thus, to avoid counter block collisions, ESP implementations that
   permit use of the same key for encrypting and decrypting packets
   with the same peer MUST ensure that the two peers assign different
   SPI values to the security association (SA)."

Is it actually kosher for two SAs to share the same keys?  SAs are
simplex per RFC 2401, though they could in principle share a single
key.  However, I'd expect that if the architecture allowed such
key-sharing that it would require that the SAs be in the same SA
bundle so that when one SA reaches it usage limit its twin gets
deleted as well.  I'm not aware of any such language, which makes me
suspicious about using the same keys twice.

Now for the real nit: at the bottom of page 7, a typo: "It is
inappropriate to use this m AES-CTR"

Best regards,

David

--

David A. McGrew, Ph.D.
Manager, Strategic Crypto Development
IOS Technologies Division
Cisco Systems, Inc. 
(301) 349 5815