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

From: "Jim Schaad" <[email-masked]>
Date: Fri, 4 Dec 2015 12:56:31 -0800

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

---

From: Christian Huitema <[email-masked]>
Date: Sat, 5 Dec 2015 01:44:47 +0000

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

> 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
> 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.
> 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.
> 
> 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
> [email-masked]
> 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

---

From: Bryan A Ford <[email-masked]>
Date: Sun, 6 Dec 2015 10:22:15 +0100

> does this not appear to help the situation.

Why are you fixated on enumerating different situations where encrypting
headers doesn't help, while completely ignoring situations where it can
help?  You could draw up an infinite list of scenarios in both
categories.  No security provision will address every possible attack
scenario - padding definitely doesn't either! - but both header
encryption and padding are complementary provisions that each make
attacks more difficult for attackers in different ways.

B

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 6 Dec 2015 13:46:25 -0800

> -----Original Message-----
> From: TLS [mailto:[email-masked]] On Behalf Of Bryan A Ford
> Sent: Sunday, December 06, 2015 1:22 AM
> To: [email-masked]
> Subject: Re: [TLS] Analysis of encrypting the headers - what is the length
> 
> > 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.
> headers doesn't help, while completely ignoring situations where it can
help?
> You could draw up an infinite list of scenarios in both categories.  No
security
> provision will address every possible attack scenario - padding definitely
doesn't
> either! - but both header encryption and padding are complementary
provisions
> that each make attacks more difficult for attackers in different ways.

Having a solid idea of what the limitations of a solution are can be
extremely helpful in trying to determine if the solution solves the problem
as presented.  My understanding of the problem that you are trying to solve
is to hid the length of the data by encrypting it.  Knowing when this does
and does not work is part and parcel of trying to do the evaluation of a
solutions effectiveness and then being able to do an evaluation of the
benefits and costs of such a solution.

It might be helpful to have a more formal set of situations where the
solution works so that it can be compared.  If the solution of encrypting
the header requires additional tactics as well, then it should be well
understood that the encryption solution is, in itself, insufficient.   Doing
so would also allow for a better understanding of what other solutions can
be used to address the same, or similar, problems potentially without the
same costs.

The question of whether padding does or does not solve the problem depends
to a large extend on what the attack model you are using is.  If the attack
model requires that you know the exact length of the data involved, then
doing a simple padding with random lengths of data, or padding out to a
fixed boundary does solve the problem entirely.  If the attack model is
based on distinguishing very large and very small blocks of data, then
padding can solve this by making all responses pad out to a very large size.
Again one needs to look at the costs of this as always sending a large
amount of data in response, most of which is padding, presents a problem for
the network and potentially the devices sending and receiving the data
(power consumption).  One therefore needs to do tradeoffs of the solution vs
the problems.  

I am assuming that your attack model more closely follows the first one
presented, but given that you have never stated it in any sort of formal
language that is at best a wild guess on my part.

Jim