Metadata in header?

[tombentley]

Currently the encryption metadata (authtag etc) is encoded into the message value. That's fine and works perfectly well, but

• it obscures that the value is encoded, and
• if you had the situation where there was a forward (client-side) proxy which was doing topic encryption and a reverse (broker-side) proxy also doing topic encryption, it means the record would get encrypted again, for (presumably) no additional benefit.

An alternative would be to use a record header with a well-known name (e.g. strimzi.io/topic-encryption). This would result in a slightly larger message overall (due to the name), but could allow that reverse proxy to recognise that the record was previously encrypted, and so avoid encrypting it again.

When intercepting Fetch response the reverse proxy would need to recognise that although this was an encrypted record, it wasn't its' encrypted record. To do that we'd need to use some unique id for logically identifying these proxies, and this would also need to be a part of the encryption metadata.

So over all, this would result in some extra bloat, and we might decide we don't want to do this, but I thought it was at least worth a discussion.

[gunnarmorling]

I'd be +1 on using headers.

Re the overhead, it's true, OTOH, would it matter too much in practice? We probably could find a shorter one (e.g. having "topic" in there doesn't make awefully lots of sense IMO, as we encrypt messages/records; at the very least, it's redundant). Plus, it could be configurable (with a sensible default ofc.), too.