Re: [TLS] Possible timing attack on TLS 1.3 padding mechanism

There's another, more cache-friendly approach too, which is to record the
position of the highest non-zero byte as the decryption occurs (while that
cache-line of plaintext is still in-cache) in-order. I found that a bit
easier to implement in constant time too because it's easy to generate an
all-1s mask that's conditional on a non-zero value.

On Thu, Mar 1, 2018 at 1:52 PM, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk>
wrote:

> Hi,
>
> I've been analysing the record protocol spec for TLS 1.3 a bit,
> specifically the new padding mechanism. I think there's a possible timing
> attack on a naïve implementation of de-padding. Maybe this is already known
> to people who've been paying more attention than me!
>
> Recall that the padding mechanism permits an arbitrary number of 00 bytes
> to be added after the plaintext and content type byte, up to the max record
> size. This data is then encrypted using whichever AEAD scheme is specified
> in the cipher suite. This padding scheme is quite important for TLS 1.3
> because the current AEAD schemes do leak the length of record plaintexts.
> There should be no padding oracle style attack possible because of the
> integrity guarantees of the AEAD schemes in use.
>
> The idea for the timing attack is as follows.
>
> The natural way to depad (after AEAD decryption) is to remove the 00 bytes
> at the end of the plaintext structure one by one, until a non-00 byte is
> encountered. This is then the content type byte. Notice that the amount of
> time needed to execute this depadding routine would be proportional to the
> number of padding bytes. If there's some kind of response record for this
> record, then measuring the time taken from reception of the target record
> to the appearance of the response record can be used to infer information
> about the amount of padding, and thereby, the true length of the plaintext
> (since the length of the padded plaintext is known from the ciphertext
> length).
>
> The timing differences here would be small. But they could be amplified by
> various techniques. For example, the cumulative timing difference over many
> records could allow leakage of the sum of the true plaintext lengths. Think
> of a client browser fetching a simple webpage from a browser. The page is
> split over many TLS records, each of which is individually padded, with the
> next GET request from the client being the "response record". (This is a
> pretty simplistic view of how a web browser works, I know!). The total
> timing difference might then be sufficient for webpage fingerprinting, for
> example.
>
> I'm not claiming this is a big issue, but maybe something worth thinking
> about and addressing in the TLS 1.3 spec.
>
> There's at least a couple of ways to avoid the problem:
>
> 1. Do constant-time depadding - by examining every byte in the plaintext
> structure even after the first non-00 byte is encountered.
> 2. Add an explicit padding length field at the end of the plaintext
> structure, and removing padding without checking its contents. (This should
> be safe because of the AEAD integrity guarantees.)
>
> Option 2 is probably a bit invasive at this late stage in the
> specification process. Maybe a sentence or two on option 1 could be added
> to the spec.
>
> Thoughts?
>
> Cheers,
>
> Kenny
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

-- 
Colm