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

From: "Peck, Michael A" <[email-masked]>
Date: Mon, 6 Jan 2014 20:26:32 +0000

Hi -

I believe two primary issues have been raised with the AES and SHA-2 encryption type drafts: ciphertext stealing vs padding, and IV options.

1: CTS vs. CBC with PKCS7 padding

We first submitted draft-ietf-kitten-aes-cts-hmac-sha2 (uses CTS mode, also known as CBC mode with ciphertext stealing), then submitted draft-ietf-kitten-aes-cbc-hmac-sha2 (uses CBC mode with PKCS7 padding).

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?

2: Initialization vector

RFC 3961/3962 sets the formal CBC IV to the cipherstate (the next-to-last ciphertext block of the previous message)  - (it's my understanding the purpose of the cipher state is to enforce message sequencing) - and sets the first block of plaintext to a 128-bit random value (called a confounder).  The cipherstate is not sent with the message since it can be implicitly inferred from the ciphertext of the previous message.  The confounder (first block of plaintext) plays the cryptographic role of the IV.

Draft-ietf-kitten-aes-cts-hmac-sha2 currently sets the CBC IV to a 128-bit nonce XORed with the cipher state (in this draft, the cipher state is currently the previous message's 128-bit nonce).  The nonce is sent in the clear along with the ciphertext and the MAC.  We followed this approach to be aligned with the CTS definition found in the NIST Special Publication 800-38A Addendum, which treats the IV as a parameter to be passed into the encrypt and decrypt operations (and expects it to meet the required properties of a CBC IV).
(Side note: Currently the draft states that the MAC is computed over the nonce and ciphertext.  Upon another look, I'm thinking the MAC should instead be computed over the IV and ciphertext, so that message reorderings are detected by the MAC verification.)

Some have indicated interest in sticking with the RFC 3961/3962 confounder approach.
I'd like to suggest some options to choose from:

Option 1:

Define separate Kerberos enctypes for each of the two IV approaches.

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

If the confounder approach is being used (as signaled by the enctype), don't include an explicit nonce.  Set the CBC IV = cipherstate.  Set the first block of plaintext to a 128-bit nonce.  Omit the first block of plaintext from the decrypt operation's plaintext output.
ciphertext || MAC is transmitted.

If the explicit nonce approach is being used (as signaled by the enctype), set the CBC IV = cipherstate XOR nonce.
nonce || ciphertext || MAC is transmitted.

The MAC is computed over the IV || ciphertext in both cases.

This option seems to provide the ability to deployers to decide which IV approaches they're comfortable with (both or just one) through the allowed enctypes.

Option 2:

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

If the sender chooses the confounder approach, set the explicit nonce field to the cipher state, and set the first block of plaintext to a 128-bit nonce (confounder).

If the sender chooses to use an explicit nonce, set the explicit nonce field to a 128-bit nonce, and set the first block of plaintext to the cipherstate.

Either way, the CBC IV is set to the explicit nonce field.
The MAC is computed over the explicit nonce field || ciphertext.

Explicit nonce field || cipher text || MAC is transmitted.

The recipient always omits the first block of plaintext from the decrypt operation's plaintext output.
The recipient needs to make sure the cipherstate transmitted with the message is consistent with the previous message's ciphertext.

Two downsides of this approach:
It adds an unnecessary 128 bits to each message.
It doesn't easily allow deployers to decide which IV techniques to allow based on policy considerations.

Option 3:

Pick one IV approach.

Thanks,
Mike

---

From: Greg Hudson <[email-masked]>
Date: Tue, 07 Jan 2014 14:54:21 -0500

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

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.)