Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

["GUBALLA, JENS (JENS)" <[e-mail]>]

> 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