> On 2 Mar 2018, at 08:32, Nikos Mavrogiannopoulos <n...@redhat.com> wrote:
>> On Thu, 2018-03-01 at 21:52 +0000, Paterson, Kenny 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.
> Hi,
> It was brought previously to the WG [0], and the bottom line was to push
> for any solution to implementations.

Thanks Nikos - sorry for missing your post from last August. At least I'm now 
only six months behind the curve :-)

> As of the "naïve implementation of de-padding", I wouldn't put like that.
> It is a straightforward method of de-padding after reading the draft, and
> I believe all implementations out there use that method.

Agreed. "Natural" would have been a better choice here. 



> regards,
> Nikos
> [0].
> https://www.ietf.org/mail-archive/web/tls/current/msg24365.html
TLS mailing list

Reply via email to