Choosing a proper nonce is a vital part of every symmetric-key encrypted communication, and it is mandatory that every encrypted message has a unique nonce. It can be shown that using a nonce twice with the same key has such catastrophic effects on the system. So in every protocol that uses AES-GCM or other AEAD algorithms, there are careful considerations for preventing the re-use of a nonce.
On the other hand, some AEAD recipes are proposed claiming to be resistant to this kind of nonce misuse, such as SIV-AES or AES-GCM-SIV. Let's accept this claim and be confident that misuse of nonce is not a problem anymore in these schemes. But I see a bigger problem: in order to authenticate the messages, they both mac the plaintext.
Quoting Moxie Marlinspike:
When it comes to designing secure protocols, I have a principle that goes like this: if you have to perform any cryptographic operation before verifying the MAC on a message you’ve received, it will somehow inevitably lead to doom.
There are also some other questions about the pros and cons of MAC-then-encrypt vs encrypt-then-MAC. It seems that the general consensus is something like MAC-then-encrypt is bad and encrypt-then-MAC is better. In other words (please correct me if I'm wrong), those block-cipher modes that mac the ciphertext (like GCM or EAX) are a better choice than the ones which authenticate the plaintext (like CCM or OCB).
So the question comes to this: the AES-GCM-SIV mode was seemingly proposed to overcome a possible vulnerability in the GCM mode, but by choosing the MAC-then-Encrypt option, they actually made it worse (or do they?) I doubt that this was a random choice and the designers of the SIV modes were unaware of the doom principle. But they deliberately chose it anyway. Is there any deeper reason behind this?
It's worth highlighting a contrast with AES-GCM here: AES-GCM authenticates the encoded additional data and ciphertext, while AES-GCM-SIV authenticates the encoded additional data and plaintext.
$\endgroup$