I have been looking into the CAESAR submissions as I'm interested in a cipher that can process a stream of unknown or large size (E.g. socket, file) while providing authentication. My understanding is that the current standard approach is for the application to slice the data into blocks and use some well-known AEAD mode like GCM (including the chunk number to prevent block suppression, duplication, and reordering).
However, ciphers like Keyak v2 take care of this by themselves by supporting intermediate tags, which combined with being online makes for a good fit for the above use case. Note that tags in Keyak v2 authenticate all plaintext chunks prior to that tag, thus protecting against suppression, duplication, and reordering of intermediate chunks; also worth mentioning that this is a Encrypt-and-MAC approach.
All this got me thinking of potential attacks against ciphers making use of intermediate tags. The way Keyak v2 is designed an attacker can't remove intermediate chunks from the ciphertext, but (s)he would be able to remove as many blocks as (s)he wanted starting from the back. This is interesting as is something you can't do against for example GCM because the MAC is applied over the whole ciphertext. A (contrived, I know) example would be for an attacker to remove the last blocks of the transmission of a number:
Original Ciphertext: 1000|Tag1|0000|Tag2
Modified Cipphertext: 1000|Tag1
The victim would have no way to detect such ciphertext modification as long as the removal of the block doesn't break the semantics of the underlying protocol (like in this example). I know that this is also possible if you're slicing the data at the application level and using GCM, but I expected the likes of Keyak v2 to solve it somehow. Unless I am missing something important, this looks like a relatively big downside of intermediate tags.
What's wrong with my reasoning? Is this just a risk we have to assume if we want to process streams in this way?