Re: [kitten] Moving forward with draft-ietf-kitten-aes-cts-hmac-sha2

[Greg Hudson <[e-mail]>]

On 01/06/2014 03:26 PM, Peck, Michael A wrote:
> A consensus call decided on CBC mode with PKCS7 padding, but immediately
> afterwards Paul Miller from Microsoft stated that CBC with PKCS7 padding
> could cause compatibility problems.  Based on that feedback, I suggest
> we go with CTS mode – are there any objections?

I think we are only likely to get consensus if we use CTS mode, yes.

> Some have indicated interest in sticking with the RFC 3961/3962
> confounder approach.

Yes.  I would summarize the advantages and disadvantages as follows:

+ eliminates most of the short input special casing
+ allows more code reuse with existing RFC 3962 implementations
+ disguises the state of a compromised PRNG (if the enctype
implementation code is not also compromised)
- less consistent with SP 800-38A addendum
- slightly slower

I believe that the first and second advantages outweigh the disadvantages.

> I'd like to suggest some options to choose from:

I am strongly opposed to defining multiple new enctypes for explicit-IV
vs. confounder, or a single enctype which tries to do both.  Doing that
would have basically all of the disadvantages and none of the
advantages.  I don't think explicit-IV vs. confounder is a "policy"
decision in any reasonable sense.  So I favor option 3.  Within that
option, I would favor a confounder over explicit-IV, but I would rather
do explicit-IV than both.

> Define the cipherstate to be the next-to-last ciphertext block of the previous message (like in RFC 3961/3962).

I am in favor of this change because it allows more code reuse.  If we
were designing from scratch, I would suggest using the encrypted
confounder as the cipherstate.

(Realistically, almost nothing uses cipherstate, so while we need a
story for it that works as well as RFC 3961/3962, we don't necessarily
need to nitpick the fine cryptographic advantages of one approach over
another.)