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

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

Steve,

personal remarks elided, your technical comments and my responses below.

Steve Kent wrote:
>
> On the topic of the overhead posed by an explicit vs. implicit IV, I
> questioned the 20-byte number you used as an example. Your rebuttal
> was vague and in no way countered my observation that the payload
> size you cited is a very misleading value. Dave Oran pointed out that
> header compression can reduce the IP header overhead, and the ESP
> header as well. But the UDP header is inside the encryption boundary,
> as are the ESP padding and pad length and NEXT field, and the ESP ICV
> is random. So, my point stands, i.e., either you were very careless
> in making the comparison between a 20-byte payload and an 8-byte IV,
> or you were intentionally skewing the argument.

No.  Perhaps I should have provided more detail when I referred to RFC2507.
>From Section 7.10:

   ... when the ESP Header is used in tunnel mode an entire IP
   packet is encrypted, and the headers of that packet MAY be compressed
   before the packet is encrypted at the entry point of the tunnel.

Also, perhaps you are unaware of the work being done to compress headers
inside of tunnels.  Examples of this work include
draft-ietf-avt-crtp-enhance-04.txt and draft-ietf-avt-tcrtp-06.txt, and much
of the work of the Robust Header Compression (RHOC) WG is applicable as
well.  It's worth nothing that compression that can be used in conjunction
with IPsec is an explicit goal of the RHOC WG.  Many of these technologies
were originally developed with voice over IP in mind, but can be used to
general benefit, especially over wireless links.

> With regard to the security evaluation boundary argument, the issue
> is exactly that sharing SA state, specifically sequence number
> values, across chip or PC board boundaries presents a limitation on
> performance. I serve (or have served) as a technical advisor to three
> different companies developing high speed crypto chips for IPsec. The
> hardware engineers in each company agree with my observation that is
> would be a fundamentally bad idea to try to maintain sequence number
> sync across chip/board boundaries, for very high speed
> implementations.

Steve, I've participated in high speed hardware designs using AES counter
mode, and we have not seen the limitation that you describe.  I think that
the best way to get to the root of our disagreement is for you to provide
more details about the design that you have in mind.  What are the goals to
which that design is aiming (10 gigabits per second?  100 gigabits per
second? 1 terabit per second?) and what assumptions does it make (use
existing chips?  use some particular ASIC technology or particular
backplane?)?  Why is it necessary to use the same key in different ASICs or
boards (which is apparently driving your concern about sequence numbers),
and why is it desirable to do so if those ASICs are within different
security boundaries?  If it is really necessary to have multiple senders for
a single key, why not use a short sender-id value?  Is the design that you
describe in brief a proprietary one or an open one?  If the latter, can you
refer to an example in the published literature?

Additionally, I do not understand your implicit contention that LFSR
synchronization would be easier to maintain across chip or board boundaries
than integer synchronization.  The synch problem is fundamental to the
movement of data, not to the algebraic mechanism by which a next-value is
generated.

> Separartely, you maintained that your employer had not encountered
> any problems in this regard, and I countered that this was probably
> because your employer was not building high assurance products, and
> thus the security boundary was very large. A check of the FIPS 140-1
> evaluated products list confirms my assertion about the assurance
> level of all Cisco evaluated products.

The FIPS-140 evaluations of Cisco gear have no bearing on this discussion.
It's worth pointing out that the approach of using the ESP sequence number
as a per-packet counter does *not* decrease security, and that you have not
even argued that it does.  What you have argued is that that approach could
prove limiting in a high-speed design - *not* that it is less secure.  That
approach does not limit the security of a system, and does not have any
bearing on the FIPS-140-2 process.

> Again, your response has not
> countered my criticisms. Instead you asked what vendors didn't
> maintain the sequence number within the security perimeter. That's
> not the point. The point is that, historically, there has been no
> need to maintain the ESP sequence counter within the perimeter for
> FIPS 140-1.

RFCs 2401 and 2406 state that "protection against replays" is one of the
goals of IPsec and that ESP provides that service by using monotonically
increasing sequence numbers.   Given this fact, how can an implementer *not*
put the ESP sequence number within the security perimeter?

On a standards level, an ESP cipher can expect a sequence number to be
unique.  From RFC2406:

2.2  Sequence Number

   This unsigned 32-bit field contains a monotonically increasing
   counter value (sequence number).  It is mandatory and is always
   present even if the receiver does not elect to enable the anti-replay
   service for a specific SA.
   ...
   <snip>
   ...
   If anti-replay is enabled
   (the default), the transmitted Sequence Number must never be allowed
   to cycle.  Thus, the sender's counter and the receiver's counter MUST
   be reset (by establishing a new SA and thus a new key) prior to the
   transmission of the 2^32nd packet on an SA.

> But, reusing it for counter mode creates that need and
> adversely limits the design space for higher assurance products.

I do not believe that the use of a monotonically increasing sequence number
limits the design space.  This is apparently the real source of our
disagreements.

>
> The above argument segues into the disagreement re the pitfalls of
> reusing ESP sequence numbers for counter mode, and what I maintain is
> an irrelevant discussion of other crypto modes.  You claim to not
> understand the security difference between sequence numbers used,
> optionally, for anti-replay, and unique values used as inputs to a
> crypto algorithm.

No, what I don't understand is the contention that the current standards do
not mandate the uniqueness of the ESP sequence number.

> The distinction is that the former use is of
> secondary security importance, as evidenced by the fact that it is an
> optional feature (for the receiver) and that is is outside the
> security evaluation boundary under 140-1/2. In contrast. the inputs
> for counter mode are security critical values that fall within the
> evaluation boundary for 140-1/2.

Sure, but the fact that anti-replay may be of lesser importance than
confidentiality has no bearing on the fact that RFCs mandate the uniqueness
of the ESP sequence numbers.

> As is so often the case, the term
> "trust" has no relevance here. The ESP sequence number plays a
> well-defined role, and reusing it for another purpose is a bad design
> approach, from a security standpoint.

Including the ESP sequence number inside the security boundary *increases*
security.

>
> With regard to the use of counters for per-packet and intra-packet
> inputs to counter mode, your response did not rebut my observation
> that the 2-fold difference in adder size was an issue ignore by your
> initial claim.

Fine, but that has nothing to do with the point that I was making: the
performance advantage of a 64-bit LFSR over a 64-bit integer increment
function is completely negligible when compared to the computational cost of
the AES-encrypting a packet.  This is an important point because
draft-ietf-ipsec-ciph-aes-ctr-00.txt uses that performance advantage as a
false premise in support of an argument as to why an implementer might want
to use an LFSR rather than counter mode.

>
> You did respond to my observations about the greater flexibility
> afforded to a product designer by a per-packet input approach that
> allows the sender to choose whatever means of generating the value
> that meets the security and performance requirements for a product.
> Your response was as assertion that the 8-byte overhead of an
> explicit IV is not worth the flexibility. This is a value judgement,
> not a technical argument. However, I am annoyed by the way you tend
> to couch the argument, i.e., as though this is an extra 8 bytes,
> whereas the reality is that the same 8-byte overhead that has been
> the default for ESP (in CBC mode) since it became a standard. So the
> question is not whether to add 8 bytes, but whether there is a
> pressing need to remove 8 bytes.

Yes, reducing the encapsulation overhead of ESP while maintaining security
is a worthwhile goal, in my opinion.

David