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

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



Steve,

I would be grateful if you would neither speculate on my personal motives
nor cast aspersions on my employer.  I refuse to be cast as a corporate
shill for presenting technical arguments and asking for WG input.

This discussion doesn't need to be adversarial.  Let's just make sure that
we've made our technical arguments clear to WG and leave it at that.

Below I have responded to the technical comments:

> -----Original Message-----
> From: Stephen Kent [mailto:kent@bbn.com]
> Sent: Friday, July 26, 2002 1:10 PM
> To: David A. Mcgrew
> Cc: ipsec@lists.tislabs.com
> Subject: 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 stand by what I said: eight bytes is a significant bandwidth hit,
especially for short packets, especially when header compression is used.

As I said, the 20 bytes cited in the example is "data per packet".  Headers
will add a significant length, though this length can be reduced
considerably in some cases through the use of header compression.  The
combination of short packets and header compression is common for VoIP.

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

I do not believe that this is a real problem, nor does anyone else with whom
I have spoken, including hardware engineers with whom I have worked on
high-speed AES counter mode designs.   If you have a detailed technical
analysis that you can provide, I would be happy to read it.  Does our
disagreement here come down to the fact that other implementers are not
multiplexing keys across chips in their high speed designs?

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

What ESP implementations don't maintain the sequence number within the
security perimeter?   I am not aware of any.  If you are, please let us
know.

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

On the contrary, this is the central technical point to our disagreement.  I
maintain that it is important for an ESP implementation to be able to
provide sequence numbers that are actually unique.  This property is useful
in counter mode and lots of other cryptographic mechanisms that are worth
using in ESP.

I'm puzzled by the claim that I shouldn't trust the sequence number.  If
cryptographic mechanisms can't trust the ESP sequence numbers to be unique,
shouldn't this fact be reflected in the RFCs?   And what can a sequence
number be trusted for?

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

True enough, but an implementation which did that would need to maintain the
sequence number within the security perimeter.

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

I stand by my analysis.  I do not believe that a 64-bit integer increment
function has a   significant computational cost relative to that of an
evaluation of the AES cipher.  I would be surprised and very interested if
you could cite work indicating otherwise.

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

Sure, it's flexible.  "Conservative in what you send, liberal in what you
accept" is a good way to design network gear.  However, is it worth eight
bytes of packet expansion?  I think that it's a question worth asking to the
WG.

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

True.

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

That's not my perception of events, but then let's stick to technical
discussion.

>
> So much for compromise.
>
> Steve

Given the fact that no requirements have been put forward for counter mode,
I think that it is sensible to operate by identifying the tradeoffs and
asking for input from the WG.

David