Subject: [kitten] New EncTypes?

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Wed, 18 Nov 2015 16:20:41 -0800

It seems to be time to do housecleaning on algorithms selections. Is anyone interested in adding a new enctype to Kerberos?

Why (else)?  Speaking strictly for myself, I’d like to see a mandatory-to-implement enctype that shares *nothing* with the current aes-sha1-hmac stuff. I’m speaking purely strategically and not from any mathematical suspicion of weakness. If someone discovers something fundamentally wrong with the math behind SHA1 or AES, then it might take out SHA2 or Camellia as well.

I have nothing specific against the “suite-B” proposal, but they’re not what I’d like to see. I assume the NSA is too busy riding the “post quantum” horse away from their DRBG fiasco to help finish it.

Just to throw some straw (just straw, not an actual strawman) on the table, how about something that uses one of the European stream cipher finalists with SHA-3?

--------

Finally, is anyone interested in doing a die-die-die draft for triple-des, or rc4?

Personal:  [email-masked]
Business: [email-masked]

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 18 Nov 2015 21:39:05 -0500 (EST)

On Wed, 18 Nov 2015, Henry B (Hank) Hotz, CISSP wrote:

> Why (else)?  Speaking strictly for myself, I’d like to see a
> mandatory-to-implement enctype that shares *nothing* with the current
> aes-sha1-hmac stuff. I’m speaking purely strategically and not from any
> mathematical suspicion of weakness. If someone discovers something
> fundamentally wrong with the math behind SHA1 or AES, then it might take
> out SHA2 or Camellia as well.
>
> I have nothing specific against the “suite-B” proposal, but they’re not
> what I’d like to see. I assume the NSA is too busy riding the “post
> quantum” horse away from their DRBG fiasco to help finish it.
>
> Just to throw some straw (just straw, not an actual strawman) on the
> table, how about something that uses one of the European stream cipher
> finalists with SHA-3?

I had heard mutterings elsewhere about a chacha20-poly1305 sort of thing,
which seems potentially interesting to me.  The real question is whether
implementors would pick up such a thing, and whether we can get consensus
for MTI.

There are public commitments to funding at least one implementation of the
aes-cts-hmac-sha2 proposal, but I don't think I've heard anything one way
or the other about a completely novel enctype.

> Finally, is anyone interested in doing a die-die-die draft for triple-des, or rc4?

There is already
https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-00

-Ben

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Wed, 18 Nov 2015 19:24:06 -0800

> On Nov 18, 2015, at 6:39 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

It’s the difference between fixing known weaknesses and (trying) to protect against unknown ones.

> https://tools.ietf.org/html/draft-kaduk-kitten-des-des-des-die-die-die-00

OK, love the name. ;-) On quick scan the content looks good too. I guess I missed it because I didn’t have my current job yet, and my life was a bit unstable.

I’ll certainly put in a strong second as being supportive of that draft (with TBD nits). However, as several have said on saag, we need to make sure we have enough good algorithms available if we want to depreciate algorithms.

Personal:  [email-masked]

---

From: Rick van Rein <[email-masked]>
Date: Thu, 19 Nov 2015 08:30:18 +0100

Hello,

> It seems to be time to do housecleaning on algorithms selections. Is
> anyone interested in adding a new enctype to Kerberos?
>
One thing I would like to bring into any such discussion is that it
would be possible to use through PKCS #11, the de-facto standard for
storing keys on tokens, including hardware keys that will never share
keys directly but allow their use through the API.  This extends the
range of possible uses for Kerberos, I think.

For instance, AES-CTS-HMAC uses plain standard AES and HMAC, and CTS can
be implemented in terms of standard CBC, so it ought to be possible to
implement with PKCS #11 (not that I've already actually tried, but it
looks possible).

Of a similar stance, I've been wanting to see more Checksum Types, such
as SHA256/384/512, for use with my TLS-KDH work.

-Rick

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 20 Nov 2015 01:04:33 -0500 (EST)

> range of possible uses for Kerberos, I think.

It is probably premature to insist on this as a requirement, but it can
certainly be a part of the discussion.

> implement with PKCS #11 (not that I've already actually tried, but it

The argument would be more compelling if there was some prior art for it,
though -- I don't know of any hardware devices implementing such a scheme
at present.

> as SHA256/384/512, for use with my TLS-KDH work.

Registering a new Checksum type is not particularly difficult, but seeing
that it gets implemented and used can be harder.  The de facto state of
affairs at present seems to be that Checksum types go hand-in-hand with
encryption types, and the required checksum for a given encryption type is
the only one ever used with it.  There may not be full support for using a
non-required checksum type with a given encryption type, but of course
use of checksums outside of traditional encryption types will require new
code anyway, so adding use of Checksums without encryption would not
present additional implementation effort other than that needed to
actually implement the new protocol feature.

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 20 Nov 2015 06:24:03 +0000

On Wed, Nov 18, 2015 at 04:20:41PM -0800, Henry B (Hank) Hotz, CISSP wrote:

> It seems to be time to do housecleaning on algorithms selections. Is anyone
> interested in adding a new enctype to Kerberos?

Yes, but see below.

> Why (else)?  Speaking strictly for myself, I�d like to see a
> aes-sha1-hmac stuff. I�m speaking purely strategically and not from any

Sharing nothing is much too radical, unlikely to get much adoption.
There is too much momentum behind AES (hardware support in modern
CPUs, ...) and no substantive evidence of any real concerns (beyond
the long-understood timing side-channel issues with naive software-only
implementations).

> Just to throw some straw (just straw, not an actual strawman) on the table,
> how about something that uses one of the European stream cipher finalists
> with SHA-3?

As a backup, sure, but SHA-3 is quite slow, and has no hardware
support.  The throught of GSSAPI wrap is largely dominated by SHA-1
performance these days.  We'd be much better off with OCB, or
another AEAD mode.

And we could use an updated set of AES enctypes, before jumping to
more exotic stream ciphers.

-- 
	Viktor.

---

From: Rick van Rein <[email-masked]>
Date: Fri, 20 Nov 2015 13:22:14 +0100

Hi,

> though -- I don't know of any hardware devices implementing such a scheme
Both AES and CBC are widely supported by PKCS #11 solutions, software
and hardware.
And CTS can be built on top of CBC, "from the outside" of the mode.  But
I do agree that
at least a demo would be nice to have.  Let's see if that drowns in my
TODO pile.

-Rick

---

From: Rick van Rein <[email-masked]>
Date: Sun, 22 Nov 2015 21:17:58 +0100

Hello Benjamin,

>> For instance, AES-CTS-HMAC [...] ought to be possible to
I made a working demonstration that generates the test vectors for
AES128-CTS based on PKCS #11 stored AES key,
https://github.com/arpa2/kerberos-pkcs11

The demo comes to the boring conclusion that a diff between what it
generates and what was stripped from the RFC is empty:

shell> make
gcc -ggdb3 -DDEBUG -I
/usr/local/src/SoftHSMv2-with-OpenPGP/src/lib/cryptoki_compat/ 
-Wl,-rpath=/usr/local/src/SoftHSMv2-with-OpenPGP/src/lib/.libs
/usr/local/src/SoftHSMv2-with-OpenPGP/src/lib/.libs/libsofthsm.so  -o
aes128-cts-pkcs11 aes128-cts-pkcs11.c
./aes128-cts-pkcs11 > output.txt
Token PIN: sekreet
diff -u testvectors.txt output.txt
shell>

I ran this against SoftHSMv2 from the OpenDNSSEC project, but there is
no reason why it would not work on hardware tokens that implement the
same API; it only relies on CKK_AES and CKM_AES_CBC, which are not
special at all.

Enjoy,
 -Rick