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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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