[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

David,

<SNIP>

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 am surprised by your comment "at Cisco we've regarded this ..." This is the IETF and as you should know, corporate endorsements for technical positions are frowned upon. You should argue for this suggested change on its merits, not on the basis of a corporate position.

I also am surprised that you cite a 20-byte "packet" size for RTP as an example. The 20 byte size makes an 8-byte IV seem very large indeed. But the 20-byte size is misleading, at best. Do these packets have no IP header? How about a UDP header. How about an ESP header & authentication trailer? How about the need to pad the ESP payload to a 4 byte boundary, which in this case adds 4 bytes to the payload? By the time you add all of these parts of the overall packet to the original 20-byte payload, the 8-byte IV is not so big an overhead anymore. Either your arithmetic is very sloppy, or you are being disingenuous.

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.

This persistent reference to Cisco positions is annoying, at best. Cisco is but one of many implementors of IPsec. As we have discussed in the e-mail among the group working on this counter mode draft, any implementation that needs to mux an SA over multiple crypto chips needs to maintain the sequence number off chip. Apparently Cisco has chosen to offer only low assurance IPsec products, e.g,. FIPS level 2 at most, so the security perimeter is very large and thus the sequence number can be maintained within that boundary. But, to impose this assurance-limiting architecture on vendors who might wish to offer higher security implementations is inappropriate.

  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.)

We're not discussing other algorithms or mode here, so none of this seems relevant to the discussion at hand. Also, if one choose to use sequence numbers for the per-packet counter inputs, I think it hard to argue that the result is far more complex that reusing the ESP sequence numbers for a function they were not designed to accommodate (from a security perspective).

  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.

Your analysis ignores the difference in the size of the two counter values. The per-packet counter is 64 bits long, while the intra-packet counter is 32 bits, and at most 28 of those bits will ever be used. Thus the propagation times are not the same.

However, you are correct in noting that the use of a LFSR would yield even greater benefit if it were employed to compute the intra-packet values. In the spirit of compromise, a spirit you have not shown in this activity, I did not press for using an LFSR for both values. The proposed compromise approach that Russ has documented allows designers more freedom, by allowing them to adopt any mechanism they wish for generating the per-packet counter input (subject to the usual uniqueness constraints) and does not require sender and receiver to negotiate a mechanism for intra-packet counter value generation.


  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.

You use the phrase "unspecified IV" as though it were a bad thing. In reality this approach, which Russ suggested, allows a designer to use whatever IV generation method works best in his/her context, without needing to get agreement among all designers, and without needing to coordinate with the peer implementation. Since it is ultimately the responsibility of the sender to ensure uniqueness for the per-packet value, this approach preserves the greatest flexibility.

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).

Any algorithm/mode document can restrict support re manual keying when it is inappropriate for the algorithm/mode. We will clarify that point in 2401bis.

I think it's worth pointing out to the WG that you and I disagreed on how to approach counter value generation from the beginning. You persuaded Russ to join the small group working on a counter mode draft, to contribute to the discussion. After coming up to speed on the issues, Russ proposed a compromise to the group, which everyone else agreed to. Now, since you didn't persuade Russ and the rest of group, you have taken the debate to the list, presenting arguments that are distorted and trying to invoke the imprimatur of your employer in an effort to persuade the WG to adopt your proposal.

So much for compromise.

Steve