> Fortunately the solution is fairly simple: the receiver simply pre- > computes and keeps in a small hash table the encrypted sequence numbers > of all packets with sequence numbers between H-W and H+W, where H is > the highest sequence number correctly received so far (the horizon) and > W is the anti-replay window size as specified in 4.1.2.5 of RFC 4347, > which typically should be 32 or 64 according to the RFC. The receiver > can precompute all these encryptions because in my proposal TLS headers > are encrypted with a stream cipher (or the AEAD operating as a stream > cipher), so it's just a matter of producing the correct cipherstream > bytes and XORing them with the uint48 sequence number. > > Whenever the receiver gets a datagram, it looks up the encrypted > sequence number in the hash table, drops it on the floor if it's not > present, and if it's present the receiver gets the decrypted sequence > number from the hash table and uses that in the AEAD decryption and > integrity-check. In the low-probability event of a hash-table > collision (i.e., two uint48 sequence numbers encrypting to the same 48- > bit ciphertext in a single 129-datagram window), the receiver can > trial-decrypt with both (or all) sequence numbers in that colliding > hash table entry. Or the receiver can keep it even simpler and just > drop all but one colliding entry, introducing a pretty low probability > of introducing occasional "false packet drops." > > The hash table is pretty trivial to maintain efficiently as well: e.g., > whenever the horizon H moves forward by delta D, remove the first D > entries from the current window and precompute another D encrypted > sequence numbers (where D will most often be 1). In the simple design > that doesn't bother dealing with hash table collisions (e.g., that > allows each hash table entry to contain only one value), perhaps don't > even bother clearing/removing old entries; just gradually overwrite > them with new ones as H moves forward.
[JG] In case there is a packet loss of at least W subsequent DTLS records: How can the receiver then ever adjust its hash table? Wouldn't that mean that no records at all would be accepted anymore? Best regards, Jens
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
