Re: [kitten] Question about AES mode in Kerberos

[Olga Kornievskaia <[e-mail]>]

May I ask a stupid question? Is there something inherently different
about nonce handling/producing in Kerberos that's different from TLS?
TLS community seems to have chosen AES-GCM as their AES mode and do
acknowledge that nonce-reuse would lead to catastrophic failures. I'm
not familiar with a solution they've chosen to adapt to avoid nonce
reuse but it seems they are not discouraged from using GCM.

I'm not sure what kind of conclusions I should draw from the
statement: "The enctype can't fit within the RFC 3961 framework (I
believe) because it requires nonce information from an upper layer."
But say NFS wanted AES-GCM it would need to negotiated it with RFC
4537 (support for this is btw I'm not sure is implemented in an MIT
library, correct?), but to do so there needs to an IANA enctype for it
(like aes128-gcm-hmac-sha256-128, aes256-gcm-hmac-sha384-192) which
there isn't one? But there are IANA numbers for AEAD_AES_128_GCM_SIV,
AEAD_AES_256_GCM_SIV? Also, you note that mixed different security
properties is problematic.

I have no performance claims about AES-GCM over AES-CBC except for
what I've read from the web. Statements such as that because each
block can be processed individually (in parallel) that it "can" allow
for better performance over AES-CBC. I can see that an implementation
can code it up serially and then no performance gains will be had.
Also, perhaps the performance gains are very small even when
implemented in parallel and that would be useful to know.

For what it's worth, I found this --
https://calomel.org/aesni_ssl_performance.html -- which is various
CPU's performance of AES-GCM, AES-CBC, and ChaCha which seem to say
that AES-GCM is faster?

My quest was simply trying to understand why TLS has decided on GCM
(which seem to be more performant, according to some) and Kerberos did
not. All of this in hopes of improving NFS over Kerberos performance.


On Sat, Jan 7, 2023 at 12:33 PM Greg Hudson <[e-mail]> 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.
>
> * GCM is a fragile encryption mode; any mistakes in the nonce input
> would lead to a catastrophic security vulnerability.
>
> * 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).
>
> * The enctype can't fit within the RFC 3961 framework (I believe)
> because it requires nonce information from an upper layer.
>
> * Microsoft's reason for interest ("something [...] for post-sha256")
> doesn't seem to match up with a GSS-only enctype.
>
> 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.
>
> _______________________________________________
> Kitten mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/kitten