Hi Andrew, > length_of_DTLSInnerPlaintext: The length (in bytes) of the serialized DTLSInnerPlaintext (two-byte integer). The length MUST NOT exceed 2^14.
Yes, the original plaintext, the original record type and the padding. For AEAD and CBC without EtM, that "length_of_DTLSInnerPlaintext" is used. > My understanding is that the DTLSCiphertext.length = length_of_DTLSInnerPlaintext + MAC Length i.e 16B for AES-GCM; I haven't implemented EtM, so I'm not sure about that. I would guess, the length of the explicit nounce is also included. You may check your implementation (AEAD and CBC MtE) against: https://github.com/eclipse-californium/californium#interop-server https://github.com/Mbed-TLS/mbedtls/pull/6264 (AFAIK, that question about EtM was raised also there.) and https://github.com/eclipse/tinydtls/tree/feature/connection_id (client only, AEAD only) best regards Achim Am 28.11.22 um 16:25 schrieb Cunningham, Andrew:
Greetings all. I was wondering could someone help clarify my understanding on the use of length fields for DTLS 1.2 + CID with respect to TLS1.3, specifically with the additional data input to the AEAD functions. If we start with the DTLS1.2 + CID’s RFC: https://www.rfc-editor.org/rfc/rfc9146.html#section-5 <https://www.rfc-editor.org/rfc/rfc9146.html#section-5> length_of_DTLSInnerPlaintext: The length (in bytes) of the serialized DTLSInnerPlaintext (two-byte integer). The length MUST NOT exceed 2^14. The enc_content field is the encrypted form of the serialized DTLSInnerPlaintext structure which is covered by the DTLSCiphertext.length My understanding is that the DTLSCiphertext.length = length_of_DTLSInnerPlaintext + MAC Length i.e 16B for AES-GCM; The protection layer definitions use these variables interchangeable in the DTLS 1.2 CID specification which is leading to some confusion (at least in my head); https://www.rfc-editor.org/rfc/rfc9146.html#section-5 <https://www.rfc-editor.org/rfc/rfc9146.html#section-5> Block Ciphers; MAC(MAC_write_key, seq_num_placeholder + tls12_cid + cid_length + tls12_cid + DTLSCiphertext.version + epoch + sequence_number + cid + *_ length_of_DTLSInnerPlaintext +_* DTLSInnerPlaintext.content + DTLSInnerPlaintext.real_type + DTLSInnerPlaintext.zeros ); Encrypt then MAC; MAC(MAC_write_key, seq_num_placeholder + tls12_cid + cid_length + tls12_cid + DTLSCiphertext.version + epoch + sequence_number + cid + *_ DTLSCiphertext.length +_* IV + ENC(cont AEAD Ciphers; additional_data = seq_num_placeholder + tls12_cid + cid_length + tls12_cid + DTLSCiphertext.version + epoch + sequence_number + cid + *_ length_of_DTLSInnerPlaintext;_* So we have some cases where the length_of_DTLSInnerPlaintext is used in the additional data and another case for Encrypt/then/MAC where the DTLS header length (DTLSCiphertext.length) as seen on the wire is used in the additional data. This seems to be slightly different for TLS1.3 which always the TLSCiphertext.length field. https://www.rfc-editor.org/rfc/rfc8446.html#section-5.2 <https://www.rfc-editor.org/rfc/rfc8446.html#section-5.2> I am trying to understand why we use different lengths for different cryptographic algorithms for DTLS and diverge from how TLS1.3 implements things. Was there some security reason for selected of length_of_DTLSInnerPlaintext vs DTLSCiphertext.length in the additional data for the various protection modes? Thanks in advance, Regards Andrew -------------------------------------------------------------- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
