From: "Peck, Michael A" <mpeck@mitre.org>
To: "kitten@ietf.org" <kitten@ietf.org>
Thread-Topic: Moving forward with draft-ietf-kitten-aes-cts-hmac-sha2
Thread-Index: AQHPCx2WFQI85VLH+06sM72V8pZqMQ==
Date: Mon, 6 Jan 2014 20:26:32 +0000
Message-ID: <CED4D260.D7E7%mpeck@mitre.org>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.3.9.131030
Content-Type: multipart/alternative; boundary="_000_CED4D260D7E7mpeckmitreorg_"
MIME-Version: 1.0
Subject: [kitten] Moving forward with draft-ietf-kitten-aes-cts-hmac-sha2
Precedence: list

--_000_CED4D260D7E7mpeckmitreorg_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi -

I believe two primary issues have been raised with the AES and SHA-2 encryp=
tion 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-kit=
ten-aes-cbc-hmac-sha2 (uses CBC mode with PKCS7 padding).

A consensus call decided on CBC mode with PKCS7 padding, but immediately af=
terwards Paul Miller from Microsoft stated that CBC with PKCS7 padding coul=
d cause compatibility problems.  Based on that feedback, I suggest we go wi=
th CTS mode =96 are there any objections?

2: Initialization vector

RFC 3961/3962 sets the formal CBC IV to the cipherstate (the next-to-last c=
iphertext block of the previous message)  - (it's my understanding the purp=
ose of the cipher state is to enforce message sequencing) - and sets the fi=
rst block of plaintext to a 128-bit random value (called a confounder).  Th=
e cipherstate is not sent with the message since it can be implicitly infer=
red from the ciphertext of the previous message.  The confounder (first blo=
ck 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 curre=
ntly 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 al=
igned 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 no=
nce and ciphertext.  Upon another look, I'm thinking the MAC should instead=
 be computed over the IV and ciphertext, so that message reorderings are de=
tected 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 previ=
ous 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 =3D cipherstate.  Set the firs=
t 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 =3D 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 ap=
proaches they're comfortable with (both or just one) through the allowed en=
ctypes.

Option 2:

Define the cipher state to be the next-to-last ciphertext block of the prev=
ious 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 non=
ce (confounder).

If the sender chooses to use an explicit nonce, set the explicit nonce fiel=
d to a 128-bit nonce, and set the first block of plaintext to the ciphersta=
te.

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 op=
eration's plaintext output.
The recipient needs to make sure the cipherstate transmitted with the messa=
ge 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 ba=
sed on policy considerations.

Option 3:

Pick one IV approach.

Thanks,
Mike

--_000_CED4D260D7E7mpeckmitreorg_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <333EBF7E5B9CDE41850138904A617039@imc.mitre.org>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
</head>
<body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin=
e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami=
ly: Calibri, sans-serif; ">
<div>Hi -</div>
<div><br>
</div>
<div>I believe two primary issues have been raised with the AES and SHA-2 e=
ncryption type drafts: ciphertext stealing vs padding, and IV options.</div=
>
<div><br>
</div>
<div>1: CTS vs. CBC with PKCS7 padding</div>
<div><br>
</div>
<div>We first submitted draft-ietf-kitten-aes-cts-hmac-sha2 (uses CTS mode,=
 also known as CBC mode with ciphertext stealing), then submitted draft-iet=
f-kitten-aes-cbc-hmac-sha2 (uses CBC mode with PKCS7 padding).</div>
<div><br>
</div>
<div>A consensus call decided on CBC mode with PKCS7 padding, but immediate=
ly afterwards Paul Miller from Microsoft stated that CBC with PKCS7 padding=
 could cause compatibility problems. &nbsp;Based on that feedback, I sugges=
t we go with CTS mode =96 are there any
 objections?</div>
<div><br>
</div>
<div>2: Initialization vector</div>
<div><br>
</div>
<div>RFC 3961/3962 sets the formal CBC IV to the cipherstate (the next-to-l=
ast ciphertext block of the previous message) &nbsp;- (it's my understandin=
g the purpose of the cipher state is to enforce message sequencing) - and s=
ets the first block of plaintext to a
 128-bit random value (called a confounder). &nbsp;The cipherstate is not s=
ent with the message since it can be implicitly inferred from the ciphertex=
t of the previous message. &nbsp;The confounder (first block of plaintext) =
plays the cryptographic role of the IV.</div>
<div><br>
</div>
<div>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). &nbsp;The nonce is sent in=
 the clear along with the ciphertext
 and the MAC. &nbsp;We followed this approach to be aligned with the CTS de=
finition found in the NIST Special Publication 800-38A Addendum, which trea=
ts the IV as a parameter to be passed into the encrypt and decrypt operatio=
ns (and expects it to meet the required
 properties of a CBC IV). &nbsp;</div>
<div>(Side note: Currently the draft states that the MAC is computed over t=
he nonce and ciphertext. &nbsp;Upon another look, I'm thinking the MAC shou=
ld instead be computed over the IV and ciphertext, so that message reorderi=
ngs are detected by the MAC verification.)</div>
<div><br>
</div>
<div>Some have indicated interest in sticking with the RFC 3961/3962 confou=
nder approach. &nbsp;</div>
<div>I'd like to suggest some options to choose from:</div>
<div><br>
</div>
<div>Option 1:</div>
<div><br>
</div>
<div>Define separate Kerberos enctypes for each of the two IV approaches.&n=
bsp;</div>
<div><br>
</div>
<div>Define the cipherstate to be the next-to-last ciphertext block of the =
previous message (like in RFC 3961/3962).</div>
<div><br>
</div>
<div>If the confounder approach is being used (as signaled by the enctype),=
 don't include an explicit nonce. &nbsp;Set the CBC IV =3D cipherstate. &nb=
sp;Set the first block of plaintext to a 128-bit nonce. &nbsp;Omit the firs=
t block of plaintext from the decrypt operation's
 plaintext output. &nbsp;</div>
<div>ciphertext || MAC is transmitted.</div>
<div><br>
</div>
<div>If the explicit nonce approach is being used (as signaled by the encty=
pe), set the CBC IV =3D cipherstate XOR nonce. &nbsp;</div>
<div>nonce || ciphertext || MAC is transmitted.</div>
<div><br>
</div>
<div>The MAC is computed over the IV || ciphertext in both cases.</div>
<div><br>
</div>
<div>This option seems to provide the ability to deployers to decide which =
IV approaches they're comfortable with (both or just one) through the allow=
ed enctypes.</div>
<div><br>
</div>
<div>Option 2:</div>
<div><br>
</div>
<div>Define the cipher state to be the next-to-last ciphertext block of the=
 previous message (like in RFC 3961/3962).</div>
<div><br>
</div>
<div>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-bi=
t nonce (confounder).</div>
<div><br>
</div>
<div>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 ciph=
erstate.</div>
<div><br>
</div>
<div>Either way, the CBC IV is set to the explicit nonce field.</div>
<div>The MAC is computed over the explicit nonce field || ciphertext.</div>
<div><br>
</div>
<div>Explicit nonce field || cipher text || MAC is transmitted.</div>
<div><br>
</div>
<div>The recipient always omits the first block of plaintext from the decry=
pt operation's plaintext output.</div>
<div>The recipient needs to make sure the cipherstate transmitted with the =
message is consistent with the previous message's ciphertext.</div>
<div><br>
</div>
<div>Two downsides of this approach:</div>
<div>It adds an unnecessary 128 bits to each message.</div>
<div>It doesn't easily allow deployers to decide which IV techniques to all=
ow based on policy considerations.</div>
<div><br>
</div>
<div>Option 3:</div>
<div><br>
</div>
<div>Pick one IV approach.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Mike</div>
</body>
</html>

--_000_CED4D260D7E7mpeckmitreorg_--