[IPsec] everything old is new again

["Dan Harkins" <[e-mail]>]

  Hello,

  I'm leaving too early to attend the ipsecme meeting at IETF 92
but I notice that draft-mglt-6lo-aes-implicit-iv is on the
agenda as "other documents".

  The idea of using an implicit IV was brought up in the IPsec WG
back in 1997 and rejected (yes, this was just for CBC mode but
that's because CCM and GCM were not designed yet). Why is
this a good idea now?

  The "unpredictable"-ness of an IV for CBC mode addresses a
chosen plaintext attack that would otherwise reduce CBC mode
down to ECB mode (and enable a codebook attack). I _think_
the draft addresses this because the IV ends up being secret
but that requires reading a bit into section 4. Namely, does one
take the "clear text payload" as plaintext and the "dedicated 16
byte key" as the key for a single ECB-style encryption using AES?
It says there's a payload and a key and it says AES is used as
a PRP but no normative text to say exactly what to do to get
this IV.

  Also, if that is the way the IV is (secretly) generated then does
this propose using a 128-bit IV, the block length of AES, for GCM?
Most implementations use the default 96-bit IV so does this
implicit construction imply some kind of concatenation or does
it propose to use a 128-bit IV with GCM? SP 800-38D describes
an RBG-based IV construction, is that what this draft is doing?

  As an aside, the Security Considerations of this draft need work.
It says that IV generation "has been left to the implementation as
long as certain security requirements are met." What are they? Do
the different modes have different requirements?  Are these
requirements met by this draft? If so, how?

  regards,

  Dan.