Hi all, I am also struggling a bit with the nonce construction for DTLS 1.3 now that we have moved to a 128-bit record_number.
The TLS 1.3 per-record nonce for the AEAD construction is formed as follows: https://datatracker.ietf.org/doc/html/rfc8446#section-5.3 1. The 64-bit record sequence number is encoded in network byte order and padded to the left with zeros to iv_length. 2. The padded sequence number is XORed with either the static client_write_iv or server_write_iv (depending on the role). In a prior version of the DTLS draft specification my understanding was we had the following: Based on the above TLS 1.3 construction, the DTLS 1.3 per-record nonce for the AEAD construction is formed as follows: 1. The 16-bit epoch and 48-bit record sequence number is encoded in network byte order and padded to the left with zeros to iv_length. 2. The padded sequence number is XORed with either the static client_write_iv or server_write_iv (depending on the role). I believe the change to 128-bit RFC sequence number records results in the following: The DTLS 1.3 per-record nonce for the AEAD construction is formed as follows: 1. The 64-bit record sequence number is encoded in network byte order and padded to the left with zeros to iv_length. 2. The padded sequence number is XORed with either the static client_write_iv or server_write_iv (depending on the role). Is my understanding correct here or am I misinterpreting the specification? I am also wondering other than the 2-bits of epoch in the AAD data for the AEAD function, what are going to use the upper 48-bits of the epoch field for? * is it solely used for the ACK/Plaintext messages now? Regards Andy On Mon, May 02, 2022 at 10:58:50AM +0200, Marco Oliverio wrote: > Hi all, > > In the RFC9147, in the last paragraph of Section 4 it's stated: > > """ > This 128-bit value is used in the ACK message as well as in the > "record_sequence_number" input to the Authenticated Encryption with > Associated Data (AEAD) function. > """ > > But the very last sentence of the same paragraph states: > > """ > In DTLS 1.3 the 64-bit sequence_number is used as the sequence number > for the AEAD computation; unlike DTLS 1.2, the epoch is not included. > """ > > Aren't these statements contradictory? > > I think only the 64-bit sequence number is meant to be used and the > first paragraph is a replace-error done while increasing the epoch > size from the last draft. Yes, the sequence number in AEAD is meant to be 64-bit. 128-bit sequence number is not compatible with any mainstream TLS 1.3 ciphersuite (since it would require nonce at least 16 octets, but all main ciphers have 12 octet nonces). And there are further problems. What is the "record_sequence_number" input? That sentence is the only match for 'record_sequence_number' in RFC9147, and there are no matches in RFC8446. I also found this in section 4.1: "If the first byte is alert(21), handshake(22), or ack(proposed, 26), the record MUST be interpreted as a DTLSPlaintext record." I presume "proposed" should not be there (ACK is indeed ContentType 26). -Ilari -------------------------------------------------------------- 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
