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

[Fabrice Gautier <[e-mail]>]

On Tue, Dec 1, 2015 at 7:27 AM, Bryan A Ford <[e-mail]> wrote:
> 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.

Hum.... I wouldn't qualify this as a "fairly simple" solution.

>
>> 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.

For example:
  A TLS library might be logically separated into two main parts:
1) A record parsing block, that just take a stream of bytes as in
input (eg: from a socket) and output a series a record.
2) A decrypt function, that take as input full encrypted record and
output a decrypted one.

There may be various reason to do this: flexibility, clean layering,
maintainability, testability, etc...

Another reason, maybe performance. For example, a network stack might
not want to send partial records to the application to decrypt. Having
a simple way for a network stack to implement TLS framing maybe
beneficial. Currently it would be fairly simple to implement TLS
record parsing in a TCP stack. But with your proposal it seems it
would mean the parsing layer would need to get keys and do crypto.


> 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.

This is all good, except that your proposal requires that the record
parsing layers has access to some AEAD API. So far it didn't need an
AEAD API at all.


> Cheers
> Bryan
>