Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-05.txt

From: Michael Jenkins <[email-masked]>
Date: Mon, 2 Feb 2015 12:28:42 -0500

Simo,

As I understand it (I inherited this draft from Kelley Burgin), the answer
is essentially because this work was submitted as a precursor to a "Using
Kerberos in a Suite B compliant manner" draft (which will be submitted as
an independent informational draft). [For the discussion of why this draft
is a kitten work item, you'd have to look at the archive.] As such, the
encryption and hash algorithm sizes are determined by the Suite B
requirements.

That said, the Suite B requirements were tuned to match what seemed to
becoming commonly available at the time, particularly in terms of
accelerated AES. So, for instance, SHA-384 is matched to AES-256, because
AES-256 had a hardware accelerated implementation. Once this pair was
selected as a Suite B level of security, it seemed reasonable to simply use
them as much as possible (and, for example, truncate the hash results) than
to require lots of other sizes as well. [Again, as this was inherited work,
I'm working from received lore.]

*That* said, there's nothing particularly Suite B about this (the enc-type)
draft, or needn't be, so I'd rather put the above seminal explanation in
the document than say "because Suite B". I propose that the following
paragraph be added to the Security Considerations section (8) to address
the entire document, rather than to litter the document with in-place
explanations:

8.2    Algorithm dimensions

Although there is nothing in this document that constrains its application,
it has been written to be consistent with common implementations of AES and
SHA-2. The  encryption and hash algorithm sizes have been chosen to create
a consistent level of protection, with consideration to implementation
efficiencies. So, for instance, SHA-384, which would normally be matched to
AES-192, is instead matched to AES-256 to leverage the fact that there are
efficient hardware implementations of AES-256.

Would this suffice? If so, I'll generate an -06 version and upload it in
time for Dallas.

Mike Jenkins
NSA
[email-masked] / [email-masked]
official email / read-everywhere email - feel free to include both

On Tue, Sep 30, 2014 at 2:10 PM, Simo Sorce <[email-masked]> wrote:

> On Tue, 23 Sep 2014 05:25:46 -0700
> [email-masked] wrote:
>
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories. This draft is a work item of the Common Authentication
> > Technology Next Generation Working Group of the IETF.
> >
> >         Title           : AES Encryption with HMAC-SHA2 for Kerberos 5
> >         Authors         : Michael J. Jenkins
> >                           Michael A. Peck
> >                           Kelley W. Burgin
> >       Filename        : draft-ietf-kitten-aes-cts-hmac-sha2-05.txt
>
> Hi while reading this otherwise very nice specification two questions
> kept popping in my mind.
>
> Why SHA-512 is not being used ?
> Why AES-192 is not being used and SHA-384 is paired with AES-256
> instead ?
> Why are you using a hash twice the size of the bit strength required,
> and chop it off, isn't HMAC supposedly not affected by birthday
> attacks ?
>
> I can guess at the rationale of some of these choices (some of it was
> discussed in IETF meetings/lists), but it would be nice to have a
> section that explains the choice or even just a reference to some other
> document that does.
>
> Regards,
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

-- 
Mike Jenkins
[email-masked] - if you want me to read it only at my desk
[email-masked] - to read everywhere else
443-634-3951

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 3 Feb 2015 13:35:41 -0500 (EST)

> Although there is nothing in this document that constrains its application,

It's not entirely clear what "constraints its application" is intended to
mean here; I would prefer an alternate phrasing.

> efficient hardware implementations of AES-256.

I wonder if there is a way to say that the combination of SHA-384 and
AES-256 as used in this document "only has 192 bits of security" (to the
extent that the concept of bits of security can even be defined).

> Would this suffice? If so, I'll generate an -06 version and upload it in

That would be fine for me, but let's give Simo some time to reply as well.

-Ben

---

From: Michael Jenkins <[email-masked]>
Date: Tue, 3 Feb 2015 22:04:21 -0500

The "constrains its application" made more sense in the original (unposted)
version of this paragraph that explicitly mentioned Suite B, before I
convinced myself that it was unnecessary (that it can be left for the
informational Suite B document). While I don't think you'd have to be
running a Suite B complaint installation for this document to be useful, it
is fair to say that the choices of hash and encryption sizes are
constraints. I would prefer to eliminate the initial clause than try to
rewrite it. So, the paragraph would start with, "This document has been
written to be consistent..."

As to the 192 bits of security, again this made more sense originally when
I had text about the Suite B 192-bit level of security. Perhaps a final
sentence, "Note that, as indicated by the enc-type name
"aes256-cts-hmac-sha384-192", the use of SHA-384 and AES-256 with a 192-bit
key provides only a 192-bit level of security." [There's a NIST special pub
under development (says their 2012 Annual Report) that talks about
what-you-get-from-what-you-used, but I'm not sure when it might be
available.]

The resulting paragraph would read:

This document has been written to be consistent with common implementations
of AES and SHA-2. The  encryption and hash algorithm sizes have been chosen
to create a consistent level of protection, with consideration to
implementation efficiencies. So, for instance, SHA-384, which would
normally be matched to AES-192, is instead matched to AES-256 to leverage
the fact that there are efficient hardware implementations of AES-256. Note
that, as indicated by the enc-type name "aes256-cts-hmac-sha384-192", the
use of SHA-384 and AES-256 with a 192-bit key provides only a 192-bit level
of security.

---

From: Simo Sorce <[email-masked]>
Date: Wed, 4 Feb 2015 02:48:02 -0500 (EST)

----- Original Message -----
> From: "Michael Jenkins" <[email-masked]>
> To: "Benjamin Kaduk" <[email-masked]>
> Cc: "Simo Sorce" <[email-masked]>, [email-masked], [email-masked]
> Sent: Tuesday, February 3, 2015 10:04:21 PM
> Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-05.txt
> 

Michael,
thank you for the explanation.

I think this wording (and this archived discussion), is sufficient to clear most
of my questions and gives enough hints to understand the logic behind these choices.

Regards,
Simo.