Re: [kitten] considering abandoning CTS mode (Re: I-D Action:draft-ietf-kitten-aes-cts-hmac-sha2-01.txt)

[Kelley Burgin <[e-mail]>]

Thanks Tom for your responses, you are correct.

>> I would not say that padding is not a concern. There is definitely concern about security vulnerabilities pursuing this course of action.  We have seen plenty of issues with CBC and padding. At the least, if there is a padding oracle then there is a problem. So there will need to be much more scrutiny if moving away from CTS. Remaining with CTS would be preferred as it would both avoid the app compat issue and security concerns. We would hate to have to disable a new cipher suite due to app compat issues or limit it to enlighted applications. 
> 
> My understanding is that the encrypt-then-MAC construction eliminates
> the known CBC padding oracle attacks.  If someone has evidence to the
> contrary, I would like to hear about it.

This is correct.

> 
>> I am curious why we aren't just using the same AES-CTS as in the current RFC?
> 
> I think the short answer is Suite B requirements and a desire to
> conform with current cryptographic best practices.

Correct again.

> 
> I believe one goal is to align with
> draft-mcgrew-aead-aes-cbc-hmac-sha2.  Earlier proposals for the Suite
> B enctypes involved GCM (I think we had a consensus that GCM wouldn't
> really work for anything invoving long-term keys), and some variant on
> the padded CBC that we're considering now, but changed to CTS mode
> because of MS-RPC related padding concerns.  It's a different CTS mode
> than the one we use for RFC 3962.

GCM will not work in a long-term key environment because of counter rollover issues.

> 
> I think part of the justification for the differences between
> draft-ietf-kitten-aes-cts-hmac-sha2-01 and RFC 3962 is to align more
> closely with cryptographic best practice.  This includes using an
> explicit IV (rather than a confounder) and using encrypt-then-MAC.
> The RFC 3962 encode-then-encrypt-and-MAC approach has been proven
> secure, but I recall that particular security result was far from
> obvious to the research community before the publication of the proof.
> 
>> Also why SHA 384 instead of 512?
> 
> I asked Kelley about this, and he said the Suite B mandate was for 128
> bits for lower security, and 192 bits for higher security.  That would
> imply SHA-384 (I think HMAC-SHA-256 should be sufficient, but they
> want an unequivocal 192 bits of strength).  I don't know why Suite B
> doesn't specify AES-192 instead of AES-256 though.  Maybe these
> rationales should be included in future revisions.

This encryption type is intended to support Suite B applications.