Re: [kitten] Question about AES mode in Kerberos

[Nico Williams <[e-mail]>]

On Sat, Jan 07, 2023 at 12:33:38PM -0500, Greg Hudson wrote:
> On 1/6/23 09:48, Olga Kornievskaia wrote:
> > I know you can't speak for them but what are the chances that MIT's
> > implementation would support it as well.
> Speaking for MIT krb5, I have several concerns about this direction:
> 
> * The motivation appears to be performance, but meaningful performance gains
> have not been demonstrated in the context of a GSS application.

I've seen a GSS-based RPC converted to TLS 1.3 w/ AES in GCM mode and
the performance improvement was ~3x.  There was no other change.

I don't think sequence number window management overhead would account
for that, and all other differences in overhead between GSS and TLS are
minimal.

> * GCM is a fragile encryption mode; any mistakes in the nonce input would
> lead to a catastrophic security vulnerability.

This is not a problem for GSS (sub-)session keys.  (Sub-)session keys
have enough entropy that we don't have to worry about their reuse, and
the IV will never be reused for obvious implementation reasons.

Because GCM is limited to 2^32 blocks of ciphertext with one key we'd
have to derive new sub-session keys before rolling over the block
counter.

> * This work creates an enctype unsuitable for general use, but which would
> require an entry in the IANA enctypes registry to be negotiable with RFC
> 4537.  Putting algorithms with very different security properties registered
> in the same registry has proven to lead to security issues (such as
> CVE-2010-1324).

I've no problem with having enctypes that are not usable outside the
Kerberos GSS mechanism.

> * The enctype can't fit within the RFC 3961 framework (I believe) because it
> requires nonce information from an upper layer.

Correct.  This is not a problem.

> * Microsoft's reason for interest ("something [...] for post-sha256")
> doesn't seem to match up with a GSS-only enctype.

A GSS-only enctype wouldn't be a general solution for that, but that
does not preclude having a GSS-only enctype.

Performance matters.

> A general-purpose enctype using AES-GCM-SIV (RFC 8452) and random nonces
> would be a better fit for Kerberos, but I don't see a good reason to specify
> it unless compelling performance gains can be demonstrated.

How does AES-GCM-SIV perform relative to AES-GCM?  If the two modes'
performance is roughly equal I'll take AES-GCM-SIV, otherwise I don't
see any reason not to have a GSS-only AES-GCM enctype.

Nico
--