On Fri, Aug 11, 2017 at 5:57 PM, Eric Rescorla <e...@rtfm.com> wrote:
> > On Fri, Aug 11, 2017 at 7:11 AM, Nikos Mavrogiannopoulos <n...@redhat.com> > wrote: > >> Imagine the following scenario, where the server and client have this >> repeated communication N times per day: >> >> client server >> --X--> >> <--Y-- >> >> >> the client puts in X a message A of 1 byte or B of 1024 bytes, and pads >> it to the maximum size of TLS record. The server replies with the >> message "ok" (same every time), padded to the maximum size just after >> it reads X. >> >> However, TLS 1.3 detects the message size by iterating through all the >> padding bytes, and thus there is a timing leak observed by the time >> difference between receiving X and sending Y. Thus as an adversary I >> could take enough measurements and be able to distinguish between X >> having the value A or B. >> >> While I'd expect these iterations to be unmeasurable in desktop or >> server hardware, I am not sure about the situation in low-end IoT >> hardware. Is the design choice for having the padding removal depending >> on padding length intentional? > > > Yes, we're aware of this, and it's an intentional design choice. The > reasoning > was that once you have the padding removed, you'll need to operate on/copy > the unpadded content somewhere, and that's timing dependent anyway. > That is certainly an incorrect assumption. gnutls for example provides a zero-copy API, and I guess it is not the only implementation to have that. > > >> There is mentioning of possible timing channels in: >> https://tools.ietf.org/html/draft-ietf-tls-tls13-21#appendix-E.3 >> However I don't quite understand how is this section intended to be >> read. The sentence for example: "Because the padding is encrypted >> alongside the actual content, an attacker cannot directly determine the >> length of the padding, but may be able to measure it indirectly by the >> use of timing channels exposed during record processing", what is its >> intention? Is it to acknowledge the above timing leak? >> > > Yes. > I am not sure if that text is sufficient to cover that issue. It seems as if the cbc timing attack is re-introduced here and pushing the fix to implementers. It may be better no to provide padding functionality with this "feature", as unfortunately it will be used by applications. regards, Nikos
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
