Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

[Nico Williams <[e-mail]>]

On Fri, Apr 17, 2015 at 03:43:52PM -0400, Benjamin Kaduk wrote:
> On Thu, 9 Apr 2015, Jeffrey Altman wrote:
> > Due to BCP 179 / RFC 6649 and draft-kaduk-kitten-des-des-des-die-die-die
> > the Kerberos protocol is left with two related AES*-CTS-SHA1 encryption
> > types for RFC 3961 based protocols.  Regardless of what track this
> > document is placed on it is going to be widely and rapidly deployed.  As
> > a result it is important that the working group ensure that the
> > encryption type is correct and that independent implementations for the
> > most widely used Kerberos implementations are available and are
> > demonstrated to be interoperable.
> 
> I don't share your confidence that this particular enctype is going to be
> widely and rapidly deployed.  I agree with the sentiment that we should
> have something other than enctypes 17 and 18, but it is not necessarily
> clear that this would be it.  There might be more excitement for something
> other than AES; I don't know.  We certainly don't have people coming to us
> (MIT krb5) and clamoring for this exact enctype...

We're definitely in shape to *add* enctypes now.  Interop issues from
dealing with 3DES and RC4 have shaken out the sorts of bugs that would
make adding new enctypes difficult.

The fact that these enctypes are simple variants on the existing ones
should help get implementations, should anyone need them.

I think there will be sites that need to move away from SHA-1, even if
HMAC-SHA-1 remains secure (which I'm not saying it does).

That said, I don't think these enctypes will generate much interest
beyond moving beyond SHA-1.  As with TLS, ideally we should add new
enctypes based on ciphers other than AES in addition to the AES ones.
For Kerberos this is much harder than for TLS due to the fact that a)
AEAD ciphers/cipher modes are all the rage now, b) RFC3961 is not
AEAD-friendly, c) if we're to use AEAD ciphermodes then we need ones
which don't require stateful nodes (i.e., which don't fall apart because
of (key, IV) reuse).  There's a relevant thread on CFRG about this right
now.

Nico
--