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. 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. regards, Nikos [0]. https://www.ietf.org/mail-archive/web/tls/current/msg24365.html _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
