Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Henrick Hellström]

On 2015-11-28 12:30, Kriss Andsten wrote:

On 27 Nov 2015, at 17:21, Henrick Hellström  wrote:


How, exactly, would this be significantly harder? The adversary will still be 
able to tell when, and how much, TCP/IP data is sent between the peers. If 
there happens to be a revealing TLS record boundary in the middle of a TCP/IP 
packet, it would seem to me there is an implementation problem rather than a 
problem with the abstract protocol.


This is actually quite common. Even when it does align with packet boundaries, it is providing 
known information rather than inferred information ("here's a length X blob, then a length Y 
blob" vs "Here's a bunch of packets whose lengths minus TLS headers amount to to 
X+Y").


Maybe I have missed something, but this seems awfully implementation 
dependent to me. Let's take a more specific example:


Suppose a web server is serving a request for a web page, which 
typically means that the client firstly sends a single HTTP request for 
the HTML page, and then multiple requests for the css, images, etc in a 
row.


Most times, the latter row of requests could easily be encoded in a 
single TLS fragment. This means that the server will become aware of all 
of the requests at the same time, and might encode all of the HTTP 
responses before beginning to encode the TLS fragments.


Carefully implemented, such a solution would not necessarily require 
significantly more resources to handle pipe-lining, compared to an 
alternative solution that would serve, encode and send the responses 
on-the-fly, and as a consequence quickly fill up the outgoing TCP/IP queue.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Peter Gutmann]

Bryan A Ford  writes:

>The idea of encrypting TLS record headers has come up before, the most
>important purpose being to hide record lengths and boundaries and make
>fingerprinting and traffic analysis harder.

Argh, no!  I sent the following to the SSH list a few days ago in support of
someone else's suggestion to finally abandon this misguided idea:

-- Snip --

SSL/TLS have used unencrypted lengths for twenty years without there being any
(known) attack or weakness based on this.  OTOH SSH has used encrypted lengths
for nearly the same period, and there have been several attacks/weaknesses
based on that.  Security-wise, it has the opposite effect of the one intended,
it makes the protocol weaker, not stronger.

My real issue with it though is that, as you've pointed out, it makes it
impossible to create an efficient streaming implementation.  With TLS you read
the length at the start, stream the rest into the target memory location, and
decrypt in place.  With SSH you have to read a single block, decrypt it, make
sure you're not providing an oracle for the attacker, copy what's left around,
read more encrypted data onto the end, decrypt the remainder, ugh.

-- Snip --

Encrypting the length information is a serious step backwards both in terms of
security and processing efficiency.

Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Roland Zink]

Am 28.11.2015 um 13:05 schrieb Henrick Hellström:

On 2015-11-28 12:30, Kriss Andsten wrote:
On 27 Nov 2015, at 17:21, Henrick Hellström  
wrote:


How, exactly, would this be significantly harder? The adversary will 
still be able to tell when, and how much, TCP/IP data is sent 
between the peers. If there happens to be a revealing TLS record 
boundary in the middle of a TCP/IP packet, it would seem to me there 
is an implementation problem rather than a problem with the abstract 
protocol.


This is actually quite common. Even when it does align with packet 
boundaries, it is providing known information rather than inferred 
information ("here's a length X blob, then a length Y blob" vs 
"Here's a bunch of packets whose lengths minus TLS headers amount to 
to X+Y").


Maybe I have missed something, but this seems awfully implementation 
dependent to me. Let's take a more specific example:


Suppose a web server is serving a request for a web page, which 
typically means that the client firstly sends a single HTTP request 
for the HTML page, and then multiple requests for the css, images, etc 
in a row.


Most times, the latter row of requests could easily be encoded in a 
single TLS fragment. This means that the server will become aware of 
all of the requests at the same time, and might encode all of the HTTP 
responses before beginning to encode the TLS fragments.
Even if it could be encoded in a single TLS fragment a simple minded 
browser may encode it one by one. Also there are many more use cases 
where such optimization may not work. Can you provide data what browsers 
are actually doing for HTTP/1.1 and HTTP2?


Carefully implemented, such a solution would not necessarily require 
significantly more resources to handle pipe-lining, compared to an 
alternative solution that would serve, encode and send the responses 
on-the-fly, and as a consequence quickly fill up the outgoing TCP/IP 
queue.


I think it is more complicated so it will use more resources. You have 
to weight what is more important, the additional "security" or the 
"overhead". Anyway I thought the decision was to hide the record length.


Regards,
Roland

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Roland Zink]

Am 28.11.2015 um 17:56 schrieb Henrick Hellström:
AFAIK, HTTP 1.1 browsers typically don't send a new request over an 
open connection, before it has received the response to the previous 
request. If that is the case, it is trivial to get the message lengths 
from the traffic, with or without encrypted TLS record headers. IOW 
you gain nothing by encrypting the length fields.


I think this is what browsers do by default. For HTTP2 this should be 
different.


Regards,
Roland

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Henrick Hellström]

On 2015-11-28 12:15, Peter Gutmann wrote:

Encrypting the length information is a serious step backwards both in terms of
security and processing efficiency.


I am inclined to +1 on that.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Tony Arcieri]

On Sat, Nov 28, 2015 at 10:05 AM, Roland Zink  wrote:

> Am 28.11.2015 um 17:56 schrieb Henrick Hellström:
>
>> AFAIK, HTTP 1.1 browsers typically don't send a new request over an open
>> connection, before it has received the response to the previous request. If
>> that is the case, it is trivial to get the message lengths from the
>> traffic, with or without encrypted TLS record headers. IOW you gain nothing
>> by encrypting the length fields.
>>
>> I think this is what browsers do by default. For HTTP2 this should be
> different.


This is HTTP/1.1 pipelining, which is supported by most browsers but
typically disabled by default as most servers don't support pipelining
correctly.

-- 
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Early code point assignments for 25519/448 curves

[Ilari Liusvaara]

On Mon, Nov 23, 2015 at 01:16:35PM -0800, Martin Thomson wrote:
> 
> Are we happy that we will only be needing the PureEdDSA variants and
> that no-one will be asking for the HashEdDSA versions?  I ask because
> I've heard it suggested (I think Karthik mentioned this) that we might
> want to sign the transcript directly in TLS 1.3 rather than rely on
> collision-resistance of the selected hash function.  That would be
> harder without access to HashEdDSA.

Also, one problem with signing the transcript directly is that because
of the context prefixes, one would either have to buffer all messages
or compute multiple hashes.

It is made worse by the fact that some hashes and signatures don't
mix very well. For example, trying to use SHA-512 with ECDSA is not a
good idea[1] (and nobody knows yet what the heck X448ph will use[2]).

Also, does the present 1-RTT construct in fact rely on collision-
resistance of the prf-hash?


[1] Well, it would be a good idea with ECDSA/P-521, but who uses
that?


[2] Proposals so far have included:
- SHA-512
- SHA3-512 (whee, SLOW)
- Shake256@512b (not a hash, but cryptographically looks OK).
- Sakee256@512b with some prefixing.
(That's just including the ones in more formal proposing, not
the earlier more handwavy proposals).


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Early code point assignments for 25519/448 curves

[Yoav Nir]

> On 28 Nov 2015, at 4:48 PM, Ilari Liusvaara  wrote:
> 
> On Mon, Nov 23, 2015 at 01:16:35PM -0800, Martin Thomson wrote:
>> 
>> Are we happy that we will only be needing the PureEdDSA variants and
>> that no-one will be asking for the HashEdDSA versions?  I ask because
>> I've heard it suggested (I think Karthik mentioned this) that we might
>> want to sign the transcript directly in TLS 1.3 rather than rely on
>> collision-resistance of the selected hash function.  That would be
>> harder without access to HashEdDSA.
> 
> Also, one problem with signing the transcript directly is that because
> of the context prefixes, one would either have to buffer all messages
> or compute multiple hashes.

I think buffering all messages is fine for a regular handshake. The problem 
begins when you have a certificateRequest later in the negotiation, leading to 
a certificateVerify which signs the entire transcript. This means that we need 
to keep the transcript for the duration of the connection just in case the 
server decides to send a certificateRequest.

If a late certificateRequest signed something other than the entire transcript, 
I would be very much in favor of signing directly.

Yoav

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Henrick Hellström]

On 2015-11-28 19:58, Watson Ladd wrote:

I think the above analysis is wrong. Consider a service written in Go
using the built-in TLS library. Then the number and sizes of writes is
visible to an attacker, which can reveal information about which
branches were taken and the data sent. That's not because the total size
of the response necessarily changes, but the sequence of writes taken to
get there.


I am not familiar with the internals of that implementation, but if the 
individual writes are immediately TLS encrypted and sent over the 
network, the timing of the TCP/IP data will likely leak a lot of 
information about the number and sizes of writes as well.


It doesn't seem like a perfect design choice to use encryption to hide 
information that will leak with non-negligible probability anyway.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls