On Fri, Aug 11, 2017 at 11:32 AM, Short, Todd <tsh...@akamai.com> wrote:
> If the plaintext length indicates a message type, then this could lead to > the issue the original query posted. In that an observer might know what > message type was passed. TLS padding is supposed to prevent this (but it > doesn’t necessarily). > > However, I argue that having TLS do significant padding for a protocol is > bad design for that protocol. It’s one thing if it’s a few padding bytes, > but the example given was 1023 bytes of padding. > > Also as pointed out by Andrei Popov, the application needs to tell TLS how > much padding to apply, so either way, the application has to deal with > determining the padding length. Why not just make it part of the protocol > in the first place? > The consensus was to provide a generic scheme that applications could use, or not. -Ekr > > OpenSSL has a callback scheme, and a block-based scheme for determining > the amount of padding. Either way, the application is involved. > > But my final point is that we are ignoring the amount of non-TLS > processing that must be done on various message types (before the response > is sent), and THAT might be even more of a giveaway than the minuscule > timing difference due to counting padding in TLS. > > -- > -Todd Short > // tsh...@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > On Aug 11, 2017, at 1:20 PM, Eric Rescorla <e...@rtfm.com> wrote: > > > > On Fri, Aug 11, 2017 at 9:47 AM, Nikos Mavrogiannopoulos <n...@redhat.com> > wrote: > >> 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 <nmav@ >>> 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. >> > > And then the next thing that will happen is that the application will read > the data, which is length-dependent. The problem is that the plaintext is > variable length. > > > There is mentioning of possible timing channels in: >>>> https://tools.ietf.org/html/draft-ietf-tls-tls13-21#appendix-E.3 >>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtls-2Dtls13-2D21-23appendix-2DE.3&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=XJYxN2Gf0rNXPl3yadis8utHDuyRetUCeYdF-OmwAcQ&s=CJUfP5OPl4Uy3Igpm9hvAvuLiJlWdRLxSnagqfNZEZM&e=> >>>> 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. >> > > I don't believe that this is analysis is correct. This timing channel only > applies to the data after message integrity has been established (i.e., > after AEAD processing), which is different from the situation in Lucky 13. > It seems like what leaks here is the length of the plaintext, which is also > what would be leaked if we simply did not have padding. > > -Ekr > > >> regards, >> Nikos >> >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
