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

[Simo Sorce <[e-mail]>]

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


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.

> On Tue, Feb 3, 2015 at 1:35 PM, Benjamin Kaduk <[e-mail]> wrote:
> 
> > On Mon, 2 Feb 2015, Michael Jenkins wrote:
> >
> > > 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's not entirely clear what "constraints its application" is intended to
> > mean here; I would prefer an alternate phrasing.
> >
> > > 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.
> >
> > 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
> > > time for Dallas.
> >
> > That would be fine for me, but let's give Simo some time to reply as well.
> >
> > -Ben
> >
> 
> 
> 
> --
> Mike Jenkins
> [e-mail] - if you want me to read it only at my desk
> [e-mail] - to read everywhere else
> 443-634-3951
>