Re: More AES suites (was: draft-ietf-ipsec-ikev2-04.txt)

[Paul Koning <pkoning@xxxxxxxxxxxxxx>]

I see two goals:

1. provide AES based suites that allow for high performance
2. provide AES based suites that match what early adopters have done
   in current chips

and yes, (2) is a valid goal; references to the standards process
don't change that.

I think this is easy to do.  Existing crypto chips typically support
CBC as the encryption mode, and HMAC as the integrity mode.  So to
support goal (2) you need modes like that, which means AES-CBC with
HMAC-SHA1. 

For goal (1) you're moving outside the range of what's in early chips,
and you get AES-CTR with AES-XCBC-MAC.  (Also, possibly, AES-CTR with
HMAC-SHA1 if someone wants that; there have been some pretty fast SHA1
implementations -- fast enough to compete with AES-XCBC-MAC?)

My point of looking at it this way is to rule out combinations like
AES-CBC with AES-XCBC-MAC.  That fits neither goal, so I don't see a
reason for having it.

       paul