Hi, On 2020-05-06 08:00 +0200, Hanno Becker <hanno.bec...@arm.com> 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
