Hi, Thanks for your input Chris, this is very helpful.
Yes, this is the way I see it. I think you can get by with implicitly authenticating things, but when you start doing this, the details of how to decode the data on the wire begin to really matter for the proof (and potentially for an attacker). This can get complicated if, as you say, the header's content is highly variable. So, I would recommend authenticating what's on the wire. I don't think it would hurt to authenticate more than this, e.g., other fields that the sender and receiver need to agree on. So far I fail to understand, on an intuitive level, why it easier to analyze the protocol when the AAD can take multiple forms potentially truncating or omitting the underlying data, but then I don't know the details and you're the expert here. If you have time though to explain a bit more where the flaw in my thinking below is, that would be great, provided it's possible. For example, another thing which I would expect to be more complicated to verify in full rigor is epoch authentication: If the epoch is reduced to its two low order bits in the DTLS 1.3 header and thus (at the moment) also in the AAD, arguing that decryption can only succeed for the correctly expanded epoch involves knowing that all epochs having different keys. That's of course true but this fact wouldn't be needed if the full numeric epoch was always explicitly authenticated in the AAD. This isn't a real issue in the end, but I would expect it to be a nuisance in a formal proof? In terms of what you mentioned regarding decoding details, it seems that adding the underlying logical header to the AAD ensures more directly that decryption can only succeed if header decoding (that is, filling in implicit data or expanding truncated data) was done correctly, whereas it is less clear with the truncated or omitted data in AAD, as in the epoch example above. Is it possible to explain what the flaw is here intuitively? Thanks again, 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls