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?
> 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.