aes-sha2 preference

[Greg Hudson]

On 09/23/2016 04:05 AM, Wang Weijun wrote:
> Now that draft-ietf-kitten-aes-cts-hmac-sha2-11 is waiting for publication and IANA already assigned numbers to the new etypes, is MIT krb5 about to support it soon?

Yes.  https://github.com/krb5/krb5/pull/535 should be merged soon, and
we expect to branch for 1.15 not long after that.

> I am mainly interested in what the preference order will be? Will the new etypes appear after existing aes128-cts and aes256-cts? Or before?

Currently in that pull request, aes-sha1 is preferred to aes-sha2, and
aes-sha2 isn't in the default supported_enctypes.  My thinking was that
while aes-sha2 comes with some security benefits (longer integrity tag,
stronger hash primitive, encrypt-then-mac):

* aes-sha1 has no known security weaknesses other than the ones inherent
to a 96-bit authentication tag (which do not lead to any practical
attacks that I am aware of).

* aes-sha1 is faster and consumes less extra token space.

* aes-sha1 is much more widely supported.  In theory this should not
matter due to enctpe negotiation.  In practice though, if aes-sha2 is
present in a server principal's keys (perhaps not as the first key, so
that tickets printed for the server are still encrypted in an aes-sha1
key) and a piece of software on the server doesn't support aes-sha2,
negotiating an aes-sha1 session key will work while negotiating an
aes-sha2 session key will not.

Nothing prevents us from changing the default order in a later release.