Re: [TLS] Choice of Additional Data Computation

[Felix Günther <[e-mail]>]

Hi,

On 2020-05-06 08:00 +0200, Hanno Becker <[e-mail]> wrote:
>> 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?

This will depend on what security you want to aim at. Clearly, if
non-malleability of headers is a goal, then yes.

More generally, cryptographic models of secure communication channels
would carve out "a ciphertext" (in quotes, as its not only the AEAD
ciphertext) from the spec. Now, it's always a modeling choice what this
ciphertext should include. A reasonable and natural choice for DTLS
would be to include the full on-the-wire header. Integrity would then
require that any modification of that header leads to the ciphertext
being rejected.
At the minimum, one would need to include all cryptographically relevant
information (esp. epoch, sequence number) enabling decryption, but then
singling those out from the wire format feels a little odd.

Hence, I would say that a natural cryptographic security notion most
likely suggests full on-the-wire header authentication. But again, it
all comes down to what's the goal.


> 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.

This depends on the perspective. For analyzing channel security, it is
often conceptually easier to follow a modular approach that combines
confidentiality under passive attacks (usually straightforward) and
integrity of ciphertexts under active attacks. The latter means: no
modification of the ciphertext on the wire is permitted (in contrast to
plaintext integrity, demanding only that no modifications to the payload
can be made). This argument hence indeed relies on headers not being
malleable.

Our security analysis [1] for example models that the decision logic of
whether receiver should be accepting a certain next packet must be
decidable from the transcript of sent and received packets so far
(publicly, without internal keys or state).
Whether this would still work with a malleable 'hint' to the logical
header I don't know. Not saying this can't work, but our analysis
doesn't speak to that.


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

Length: no.
Sequence number (and epoch): only minor, as it merely obviates one level
of indirection (authentication via the nonce input).


Cheers,
Felix

[1] Marc Fischlin, Felix Günther, Christian Janson. Robust Channels:
Handling Unreliable Networks in the Record Layers of QUIC and DTLS.
Preprint for QUIPS 2020 Workshop at https://felixguenther.info/Q20_RC.pdf