Re: [TLS] Choice of Additional Data Computation

[Hanno Becker <[e-mail]>]

Hi Felix,

Thanks for chiming in!

> First of all, let me make sure I correctly understand that
>  * "on-the-wire header" is what's exemplified in Fig. 4 of the draft
>  * "pseudo-header" would be a superset, esp. including full epoch, full
> sequence number, length, connection ID, ... -- what else?

Perhaps version and content type, though at least the latter is fixed.

> Further, I understand there is _no_ unique mapping from pseudo-header to
> on-the-wire header (as the latter may be compressed in different ways).

Yes.

> The latter, to me, suggests that authenticating the pseudo-header alone
> may not be sufficient. It would at least allow on-path modifications to
> the on-the-wire header, which I don't expect is intended.

Can we go a bit into this? As mentioned in the original thread
https://mailarchive.ietf.org/arch/msg/tls/VK9e6fA9jdQVFc6tQNWNO8OThU8/
there are some (arguable) considerations of why it has practical benefits
to not cryptographically bind the header _format_ to the record.

Those considerations, however, are secondary to security considerations,
so they didn't surface here so far.

Could we therefore clarify:

Are there any _security_ concerns arising from the modifiability of the
header format assuming the underlying pseudo-header is bound via AEAD?

I don't see one so far, but might miss something. In my head, once the logical
data is authenticated, the entire on-the-wire header merely degrades to a 'hint'
to the receiver as to what the logical header data is, the precise form of which
is entirely irrelevant.

_If_ there are no security concerns (and only then), I'd like to bring up those secondary
considerations from https://mailarchive.ietf.org/arch/msg/tls/VK9e6fA9jdQVFc6tQNWNO8OThU8/
regarding modularity, efficiency and flexibility again, arguing in favor of purely logical AEAD
omitting the wire-format.

> 1) The length is implicitly authenticated through the ciphertext itself
> -- tampering with the ciphertext, in particular its length, will make
> AEAD decryption fail.
> 2) The full sequence number is implicitly authenticated through the
> nonce -- decoding the wrong sequence number will (offset by the IV)
> yield a different nonce, leading AEAD decryption to fail.

Would you expect a change in proof complexity when switching
to explicit length and sequence number authentication in the AEAD?

>  4) I slightly disagree with "epochs determine the key" (true) as, what
> I understand is, an argument that "the full epoch is implicitly
> authenticated by using the right key", at least in its absoluteness. My
> *guess* would be that, due to the key schedule, this argument comes down
> to the probability of keys colliding (which is anyway to be avoided, so
> probably fine). Still, from a security analysis point of view, showing
> security with key updates might be easier if the (full) epoch was
> authenticated as part of the AAD.

Yes, that matches my thinking above - it's probably practically fine, but
a formal argument gets more complex without explicit epoch authentication
because it involves the mapping { epoch id } -> { keys }.

Regards,
Hanno
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.