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

[Christian Huitema <[e-mail]>]

On Friday, December 4, 2015 12:57 PM, Jim Schaad wrote:
> To: [e-mail]
> Subject: [TLS] Analysis of encrypting the headers - what is the length
> ...
> 
> 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.

Some DTLS applications that care about privacy. An example is DPRIVE -- DNS over DTLS, or over TLS. The length of the packets matter. The length of cipher-texts for query and responses can enable guesses on the length of the name being looked at, and that's precisely what DPRIVE is trying to prevent. But then the answer is not to encrypt the length, because as Jim says it can be deduced from the size of the UDP packets, or even the patterns of the TCP stream. The solution instead is padding, either using the TLS 1.3 mechanism, or using the DNS padding option that DPRIVE is standardizing. 

There are debates on how much to pad exactly, e.g. to the max MTU or to some logarithmic scale. Will probably take some time to assess the best strategy. But it is going to happen.

-- Christian Huitema










> 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
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ie
> tf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7chuitema%40microsof
> t.com%7c329977d637c04d729a5708d2fcedcbc2%7c72f988bf86f141af91ab2
> d7cd011db47%7c1&sdata=cNl1i6bnNSNrsPR%2bZ9JHOiepttgz6nRmoIQn7en
> Exto%3d