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

[Michael Jenkins <[e-mail]>]

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
[e-mail] / [e-mail]
official email / read-everywhere email - feel free to include both

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

> On Tue, 23 Sep 2014 05:25:46 -0700
> [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/kitten
>



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