Re: The TLS hammer and resource integrity

  
one thing I haven't seen discussed is the latency introduced in setup 
of TLS.
  
if you think TCP 3-way handshake is bad, TLS handshake adds at least 
another 2 full RTTs.
  
This means my 300ms connection to a (non geolocated) US site becomes a 
1s one.
  
I would have thought that ALONE would have been a show-stopper.
  

------ Original Message ------
From: "Poul-Henning Kamp" <phk@phk.freebsd.dk>
To: "Amos Jeffries" <squid3@treenet.co.nz>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 28/03/2012 8:21:21 p.m.
Subject: Re: The TLS hammer and resource integrity
>In message <f46d469093a1a7d6a357d77a68217002@treenet.co.nz>, Amos Jeffries writ
>es:
>
>
>>
>>I completely agree that this needs to be addressed, but the transport
>>appears to be doing everything right so far.
>>
>
>
>Everything, that is, except performance and choice.
>
>There is no way to get around that mandatory TLS is overkill in
>many high-volume applications, most notably p0rn.
>
>If you want to kill HTTP/1.1, you have to make HTTP/2.0 a good idea
>for the 50% of web traffic consisting of pink bits.
>
>Second, there are places where TLS is simply not a good idea, either
>because other security measures are in place, or because transparency
>is specifically called for (Think: Flight Recorder).
>
>--
>Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>phk@FreeBSD.ORG         | TCP/IP since RFC 956
>FreeBSD committer       | BSD since 4.3-tahoe
>Never attribute to malice what can adequately be explained by incompetence.
>
>
>

Received on Wednesday, 28 March 2012 07:45:18 UTC