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

[Stephen Kent <kent@bbn.com>]

At 5:30 PM -0700 7/26/02, David A. Mcgrew wrote:
>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.


I agree that this debate should be technical, but your message 
clearly shows that you tried to bring the imprimatur of your employer 
into the discussion.  Your behavior, in terms of the wording of the 
message, and in terms of the design team process, further earned you 
the personal criticisms I levied. Your indignant disclaimer is out of 
place.

So, let's look at the technical arguments you made, my responses, and 
your comments to my responses. To avoid needless message expansion, I 
have summarized:

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. My point about 
inappropriately referring to your employer in this argument, 
presumably to lend it greater weight, also stands.

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.

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. 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. But, reusing it for counter mode creates that need and 
adversely limits the design space for higher assurance products.

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. 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. 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. Ask one of your colleagues who 
has first hand experience with the security evaluation process; 
perhaps they can explain this notion better than I.

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.

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.

Finally, you dispute, thought only faintly, my characterization of 
the history of the design team and how we got to this point. There 
really is little ambiguity here. Russ was added to the team at your 
invitation. One might argue about whether you asked him to join in an 
effort to sway the team to your proposal. It is a fact, however, that 
Russ developed a compromise document, that the rest of the design 
team agreed to it, and that you choose to bring your arguments to the 
list in an effort to reject the compromise.

Steve