Subject: Re: [kitten] Request for summary of issues with existing AES-CTS with new SHA2

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 1 Nov 2013 11:35:16 -0400 (EDT)

Hi Michiko,

On Wed, 30 Oct 2013, Peck, Michael A wrote:

> Michiko,
>
> First, regarding the CTS vs. CBC with PKCS#7 padding question, we the document editors are of course happy to go along with whatever consensus the working group comes to.
> Our latest CTS-based draft is at: http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-01
> Our latest CBC with PKCS#7 padding draft is at: http://tools.ietf.org/html/draft-ietf-kitten-aes-cbc-hmac-sha2-00
>
> In the Introduction of both drafts we have a section describing the differences between them and the existing Kerberos AES specification (RFC 3961/3962).
> Our goal was to update to SHA2 and also follow current best cryptographic practices.
> For example, unlike RFC3961 we follow the current best practice of Encrypt-then-MAC.
> For CTS, we use the definition in the NIST Special Publication 800-38A Addendum, which uses an explicit IV instead of a confounder.
> Unfortunately the NIST definition doesn’t deal with plaintext lengths equal to or less than the AES block size, so we added text in Section 5 to cover that situation for completeness, even if it might never happen in reality.
>
> The CTS draft states:
>
> *  The pseudorandom function used by PBKDF2 is HMAC-SHA-256 or HMAC-
>      SHA-384.
>
>   *  A key derivation function from [SP800-108<http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-01#ref-SP800-108>] which uses the SHA-256
>      or SHA-384 hash algorithm is used to produce keys for encryption,
>      integrity protection, and checksum operations.
>
>   *  The IV used during content encryption is sent as part of the
>      ciphertext, instead of using a confounder. This saves one
>      encryption and decryption operation per message.
>
>   *  The HMAC is calculated over the AES output, instead of being
>      calculated over the plaintext.  This allows the message receiver
>      to verify the integrity of the message before decrypting the
>      message.
>
>   *  The HMAC algorithm uses the SHA-256 or SHA-384 hash algorithm for
>      integrity protection and checksum operations.

As Michael notes, a goal for the new enctypes was to bring us into line 
with current cryptographic best practices, with the two most relevant 
practices being CBC mode and the use of an explicit initialization vector 
(instead of the random confounder used in the previous kerberos encryption 
types).

I believe that Paul's clarifications about the potential issues have 
brought about a general sentiment in the working group that the CBC mode 
(with explicit padding) is too risky to introduce at present.  That leaves 
only the IV versus confounder question, which is the source of the issues 
with CTS mode.

With CTS mode such as in NIST SP-800-38A (2010 appendum), the input 
plaintext is required to be at least a complete block long.  This is the 
source of our long discussions and the reason why many people were pushing 
for CBC mode -- we would need to specify some one-off solution for what to 
do with short plaintexts (as an RFC 3961 enctype does not place 
restrictions on the length of the plaintext input to the encryption 
operation), and the solutions being propsed were getting rather 
complicated.  Having two completely different algorithms for the 
encryption procedure, only one of which is commonly used, seems to be 
asking for trouble.  The draft-ietf-kitten-aes-cts-hmac-sha2-01 linked 
above has a conditional on (L(P) > c) in the encryption function, for 
an example of the "completely different algorithms".

There has also been the question raised of whether sending an explicit IV 
has risks of its own (namely, exposing state of the random number 
generator) and should actually be best current practice.  I don't believe 
that there is consensus on the list on this question, and speaking for 
myself, I'm not convinced that this list is the right place to settle such 
a question.  If we did abandon the idea of sending an explicit IV and go 
back to the existing practice of using a random confounder, then the 
plaintext input to the cipher mode will always have a confounder and thus 
always be at least a block in length, eliminating the need for a separate 
"short plaintext" case in the encryption/decryption routines.

We as a group must weigh the tradeoff between following cryptographic 
best practice and ease of implementation, taking into account the other 
issues that have been raised.

Speaking just for myself, while Paul's description of why padded ciphers 
might cause trouble for applications is convincing enough that I agree we 
should not intorduce new enctypes with padding now, I do feel that we 
should try to give ourselves the option of adding it at some future time. 
It would really be a shame if we found ourselves locked into some practice 
from N years ago and could never migrate to best practices as a result.  I 
know that all applications have a depreciation cycle and will eventually 
stop working as OSes advance, and I would hope that we could use this 
(slow-paced) cycle to winnow out applications which are unprepared for the 
possibility of padding, so that maybe in 10 years we could revisit the 
question.

Alternately, NIST could have a competition for a stream cipher, that would 
be good, too.

-Ben