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

[Bryan A Ford <[e-mail]>]

On 12/1/15 4:02 AM, Fabrice Gautier wrote:
> 1) What would be the implications of this for DTLS? (Knowing that one difference between TLS and DTLS is the record header)

Good question.  Fortunately my proposal should be fairly easy to adapt
to DTLS, with one small trick.

The main issue is that DTLS packets need to contain explicitly
transmitted sequence numbers rather than implicit sequence numbers,
because packets can be received out of the order and the receiver needs
to know which sequence number (and hence which nonce) to use to try to
decrypt and integrity-check.  But if we encrypt the full DTLS header
including sequence number, how does the receiver decrypt it without
knowing the correct nonce to use to decrypt it?  An apparent
chicken-and-egg problem.

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.

> 2) In some implementations the record framing/parsing and encryption/decryption are down at different layers. Would this proposal make this type of implementation impossible? 

Not that I'm aware of, but I might need more information about the
specific layering approaches you're thinking of and how "strongly
enforced" that layering might be.  But in the version of my proposal
that operates the "normal" AEAD as a stream cipher for header
encryption/decryption purposes, it doesn't seem like any change would be
needed to the standard AEAD encryption/decryption interface.  It should
even be fine if the AEAD was implemented as a separate hardware module
that takes the standard AEAD interface inputs and produces the standard
AEAD outputs; as long as it supports the standard AEAD API it should be
perfectly usable in the design I proposed.

The one potential issue I can think of if a particular, restricted API
forces the caller to commit at key-setup time to either "AEAD encryption
mode" or "AEAD decryption mode", and makes it difficult or impossible to
switch back and forth.  In that case in my proposal as it stands the
receiver TLS implementation might need to set up and maintain two
hardware contexts, one for AEAD decryption (for the payloads), the other
for AEAD encryption (for stream cipher header decryption), both using
the symmetric key.  This still doesn't seem all that problematic to me,
though, and I don't even know of any particular APIs offhand that
present this particular issue.

Cheers
Bryan