[TLS] Analysis of encrypting the headers - what is the length

["Jim Schaad" <[e-mail]>]

I will start by re-iterating my initial position that I would prefer that
the DTLS and TLS analysis is going to be the same in terms of masking the
header information.  So I decided to do some thought experiments about what
happens if the length were to be encrypted and how many different situations
does this not appear to help the situation.

DTLS  - Given that most DTLS situations are going to want to keep the block
of data sent small, there is no to little incentive to send multiple DTLS
blocks in a single UDP packet.  This means that the length of the encrypted
data is going to be easily found based on the length of the UDP packet.
One can probably make some significantly accurate guesses about what the
header fields are going to be for a DTLS packet, but I would assume that
even if the key could be determined it would not compromise the keys used in
protecting the D/TLS content itself.

TLS w/ lock step protocol - Think about using TLS with a lock step protocol
such as exists for POP where you always have a situation where the client
sends a request and the server sends a response.  Even with the length field
encrypted a traffic analysis is going to be able to determine the length of
all of many of the messages based on the amount of data that is flowing from
each of the end-points.  Thus with POP I can make a good guess about the
length your password just by looking at the traffic being sent in terms of
raw byte counts even without the length being directly available.

TLS w/ time breaks between operations - Think about doing browsing on a web
site.  I read a page, which takes time, and then I click a link.  Looking
just at the traffic flow I can make a really good guess about the length of
the link that you just sent to the server based on the number of bytes that
are sent from the client to the server before the server starts chattering.
Any protocol where there are going to be times where there is silence
followed by a request and then responses is going to all for a relatively
easy guess about the length of the request based just on the number of bytes
in the stream.

These are all situations where if one say - My attack model is that exposing
the length of the encrypted data allows the attacker to obtain significant
information about what I am sending - then the simple expedient of
encrypting the header information is clearly insufficient to deal with the
attack proposed.  Additional steps need to be taken as well.  For example
sending all of the randomly updating adware back on the same TLS channel to
prevent time breaks from occurring.  (What a horrid idea of using adware as
a method of preventing attacks.)

I believe that this is the type of analysis that Peter is looking for in
terms of what is the attack you are trying to prevent, what does the
proposed remedy actually do what you think it does.  The situations above
would all appear to be better dealt with padding of the plain text in some
manner rather than encrypting the length field.

Jim