As I like to make my tin-foil hat using only the finest quality metal, I was overjoyed to see that Firefox/NSS (I'm using Arch Linux) has recently added support for the P-521 ECDH group in compatibility with TLS 1.3 (albeit not part of suite B).
It has supported ECDSA public keys using the secp521r1 named curve for a long time and AES256 (in some form) for a very long time.
For the first time in a very long time (or possibly ever) it seems to me that it is now possible to actually achieve 256 bits of effective symmetric security taking into account the weaknesses in other components of the crypto stack.
I am basing this assumption on an oft cited academic paper [did not see the need to dig it up for this question but it was put together by top men] that set out the corresponding public key length in RSA and EC terms for a given symmetric key length. This paper effectively says 2048RSA is roughly equivalent to 112bits and that EC key lengths are roughly half the strength of symmetric keys (i.e. secp256k1 == 128bits).
Now, TLS 1.3 has a maximum SHA2 level of 384bits and Firefox does not exceed the standard in this respect. The specific cipher suite am deploying is ECDH-AES256-GCM-SHA384 (w/ P-521).
My question to crypto.SE is- what am I losing in terms of encryption security by having client browsers supporting a max of SHA384?
My question has two supporting addenda/subqueries: Firstly, the checksum would seem irrelevant to me given I'm using an AEAD (AES256GCM) cipher. What am I missing here?
Secondly, in case somehow I'm missing the point and (speculating) the SHA384 somehow refers to authentication with respect to the ECDH component of the stack- is my risk here (assuming my attacker can find collisions for SHA384 but NOT for SHA512) that my attacker can inject false messages into my communications or could it (very remotely) strengthen my attacker's ability to decrypt my communications?
Finally, I'm well aware that the weakest link in my attack surface area is in so many other easier places than the cryptographic primitives, however, for the sake of good tin foil and for my OCD, it would be really lovely to get some guidance.
Finally- oh how it would be nice for every browser and every crypto library in the world to support AES, Threefish, quantum resistant algos, Ed448 (Big one that I would trade the others for), SHA3, Twofish, etc. Add all this bloat in and leave it to implementers to configure and choose wisely.