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

Reply via email to