Subject: [kitten] Call for Adoption: draft-burgin-kerberos-aes-cbc- hmac-sha2.

From: Sam Hartman <[email-masked]>
Date: Wed, 13 Feb 2013 09:05:53 -0500

The chairs have received a request fromKelley Burgin to consider
draft-burgin-kerberos-aes-cbc-hmac-sha2 as a kitten draft.  The chairs
would like to solicit comments on whether to adopt this draft and on
whether it should be standards-track or informational.
Please submit comments by March 2, 2013.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Wed, 13 Feb 2013 15:22:07 +0000

This dradt uses cbc. Is the considerations that made us use cts mode/padding no longer important (dce/ms-rpc) ?

Skickat från min iPad

13 feb 2013 kl. 06:08 skrev "Sam Hartman" <[email-masked]>:

> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Feb 2013 09:57:53 -0600

> This dradt uses cbc. Is the considerations that made us use cts mode/padding no longer important (dce/ms-rpc) ?

The -02 seems to have switched to CTS, but the edits for that change
are incomplete.

I assume that a -03 will complete the switch to CTS.

No motivation is given for the new enctypes, but I assume it's the
obvious motivation: to move away from SHA-1.

As for CBC vs. CTS, we really want CTS for reasons having to do with
the SSPI -- we want the only ciphertext expansion to be of static size
and to result from a) the use of a confounder (this is done in
RFC3961, so this I-D needn't mention confounders any more than
RFC3962), and b) the authentication tag (the MAC).

CTS does have its problems, namely that it's hard to implement in
terms of CBC: it's difficult to implement CTS using cryptographic
coprocessors.  The best one can do is use two (and sometimes three)
AES-CBC cryptographic coprocessor operations  The AES-NI instructions
make this less of a concern.

Nico
--

---

From: Kelley Burgin <[email-masked]>
Date: Wed, 13 Feb 2013 11:28:05 -0500

These enctypes are to support draft-burgin-kerberos-suiteb, so the  
move from SHA-1 was the major motivation. We switched to CTS in -02  
after the discussion on DCE/MS-RPC a year or two ago. The other major  
difference is we mac the ciphertext instead of the plaintext.

I didn't intend for the draft to be incomplete in the switch to CTS  
and would certainly appreciate more detailed comments on revisions  
needed.

Kelley

On Feb 13, 2013, at 10:57 AM, Nico Williams wrote:

>> This dradt uses cbc. Is the considerations that made us use cts  
>> mode/padding no longer important (dce/ms-rpc) ?
>

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Feb 2013 10:31:28 -0600

On Wed, Feb 13, 2013 at 10:28 AM, Kelley Burgin <[email-masked]> wrote:
> These enctypes are to support draft-burgin-kerberos-suiteb, so the move from
> SHA-1 was the major motivation. We switched to CTS in -02 after the
> discussion on DCE/MS-RPC a year or two ago. The other major difference is we
> mac the ciphertext instead of the plaintext.
>
> I didn't intend for the draft to be incomplete in the switch to CTS and
> would certainly appreciate more detailed comments on revisions needed.

Well, the abstract still says "CBC"...  :)

Also:

 - the title says nothing about cipher mode
 - the footer still says CBC in the shortened form of the title
 - appendix A's title still says CBC
 - paragraph 2 of section 1 still says CBC...
 - ...

You might want to do a global search and replace.

Nico
--

---

From: "Peck, Michael A" <[email-masked]>
Date: Mon, 18 Feb 2013 14:19:44 +0000

In the draft, rather than call it "CTS mode", we refer to it as "CBC mode with ciphertext stealing" or the "CBC-CS3 variant to CBC mode" as defined by the NIST SP 800-38A Addendum.
I'm thinking we want to revise the draft to clarify that we do mean the same CTS mode used by the other Kerberos enctypes, but while pointing to CBC-CS3 defined by the NIST SP 800-38A Addendum as the normative reference for the mode.
Any comments on that or the rest of the draft would be terrific.

Thanks,
Mike 

>-----Original Message-----
>From: Kelley Burgin [mailto:[email-masked]]
>Sent: Wednesday, February 13, 2013 11:28 AM
>To: Nico Williams
>Cc: Love Hörnquist Åstrand; Sam Hartman; [email-masked]; Peck, Michael A
>Subject: Re: [kitten] Call for Adoption: draft-burgin-kerberos-aes-cbc- hmac-
>sha2.
>

---

From: Sam Hartman <[email-masked]>
Date: Mon, 18 Feb 2013 10:13:32 -0500

>>>>> "Peck," == Peck, Michael A <[email-masked]> writes:

    Peck,> In the draft, rather than call it "CTS mode", we refer to it
    Peck,> as "CBC mode with ciphertext stealing" or the "CBC-CS3
    Peck,> variant to CBC mode" as defined by the NIST SP 800-38A
    Peck,> Addendum.  I'm thinking we want to revise the draft to
    Peck,> clarify that we do mean the same CTS mode used by the other
    Peck,> Kerberos enctypes, but while pointing to CBC-CS3 defined by
    Peck,> the NIST SP 800-38A Addendum as the normative reference for
    Peck,> the mode.  Any comments on that or the rest of the draft
    Peck,> would be terrific.

Note that I think people are more concerned about avoiding ciphertext
expansion than which CTS mode you mean.  It's find to clarify as you
propose.  However, I think for this community the important
clarifications are to the areas Nico called out.

---

From: "Peck, Michael A" <[email-masked]>
Date: Mon, 18 Feb 2013 20:42:30 +0000

Thanks.  Nico, do you currently see any other necessary clarifications besides making it clear that we are using CTS aka CBC-CS3?
Currently the ciphertext expansion is of static size.
The final ciphertext length is the length of the IV (128 bits) + the length of the plaintext + the length of the MAC (either 128 bits or 192 bits depending on the enctype).
We can make that clear in the draft.
Also unlike RFC3961 the MAC is computed over the IV and ciphertext rather than over the plaintext.

Mike

>From: Sam Hartman [mailto:[email-masked]]
>Sent: Monday, February 18, 2013 10:14 AM
>To: Peck, Michael A
>Cc: Kelley Burgin; Nico Williams; Love Hörnquist Åstrand; Sam Hartman;
>[email-masked]