Hi, I've a query on the reconstruction of the sequence number from the DTLS 1.3 specification: https://www.rfc-editor.org/rfc/rfc9147.html#name-reconstructing-the-sequence <Text> "If the epoch bits match those of the current epoch, then implementations SHOULD reconstruct the sequence number by computing the full sequence number which is numerically closest to one plus the sequence number of the highest successfully deprotected record in the current epoch." </Text>
Using the text above with the following example. Current Highest deprotected record = Top of Window (ToW) = 0x0000_01B2, Adding one we get 0x0000_01B3 If the "expected" Seq num transmitted was 0x0000_0133 and S=0, we will just observe 0x33 in the DTLS header. There are three potential candidates for 0x33 which we can predict based on the specification above: A) 0x0000_0233 B) 0x0000_0133 C) 0x0000_0033 The absolute delta between the candidates and the highest successfully deprotected record plus one is: A) 0x0000_01B3 - 0x0000_0233 = ABS(-0x80) = 128 decimal <potential candidate?> B) 0x0000_01B3 - 0x0000_0133 = ABS(0x80) = 128 decimal < potential candidate?> C) 0x0000_01B3 - 0x0000_0033 = ABS(0x180) = 384 decimal <not a candidate> As you can see from above, we have two predictions which are numerically closest to the ToW plus one. I don't think it's possible to select the correct value when using the approach recommended in the RFC. 8( Should the standard be amended to use something like the IPSEC reconstruction scheme which takes the bottom of the window into account? https://www.rfc-editor.org/rfc/rfc4303#page-40 Regards Andrew -- "The large print giveth, and the small print taketh away"
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
