MAC where key is provided afterwards I was just wondering if there is a MAC scheme where the key provided after part of the message has been hashed. I was just looking at TLS 1.3 and a comment of Thomas Pornin where the messages needed to be stored before they were hashed with the session key. But I wonder if it isn't easier to first hash the messages and then provide the key.

Of course the hash algorithm would have to be established, but the ciphersuite is established after the Server Hello message. In that case it could be benificial to something similar to $\operatorname{HMAC}_{K_{mac}}(\operatorname{H}(M_1 | M_2 | M_3))$ (where M is a handshake message), but preferably with a single primitive.

Is there a reason that the key is put in first within HMAC / or SHA-3 / KMAC? Are there reasons that the key cannot be put in last? Or are there schemes that already do this?
If you have a secure MAC algorithm $M$ and a collision-resistant hash function $H$, then you can define another secure MAC algorithm $M'$ such that $M'(x) = M(H(x))$. Historically, though, HMAC was defined as a construction that provides reasonable security as a MAC even for an underlying hash function which is a bit flaky in that respect (in that case, Merkle-Damgård functions like SHA-1, that suffer from the so-called length extension attack, which illustrates the subtleties of MAC-building out of hash functions).

(For reference, my comment in the TLS-1.3 mailing-list is about the need to buffer incoming data until the MAC can be verified; this is unrelated to the moment the key is injected in the MAC process.)