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 _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
