On Sat, Aug 2, 2014 at 5:27 PM, Watson Ladd <[email protected]> wrote:
>
> The third one has a major latency hit because TLS requires superfluous
> rounds of negotiation.
Hmm... Unless I am confused, here are the packet flows.
Best seen with fixed width fonts.
The tcpcrypt proposal looks like this:
Client Server
---------------------------------------------------------
SYN/HELLO ->
<- SYN/ACK PKCONF, pub-cipher-list
INIT1, sym-cipher-list, N_C, pub-cipher, PK_C ->
<- ACK, INIT2, sym-cipher, KX_S
<- Data
Data ->
So the first time that anyone can send data is the server
on the fourth message. The client can send data on
receiving that message.
The TLS proposal looks like this (with TLS 1.2)
Client Server
---------------------------------------------------------
SYN/OPTION ->
<- SYN/ACK OPTION
ACK ->
ClientHello ->
<- ACK, ServerHello, etc.
ClientKeyExchange, etc. ->
Data ->
<- Finished
<- Data
Finished ->
The client can send at the same time here as with tcpcrypt
if he is doing False Start. The server can send one round trip
later, which is worse than tcpcrypt.
If you are doing TLS 1.3, then it looks like:
Client Server
---------------------------------------------------------
SYN/OPTION ->
<- SYN/ACK OPTION
ACK ->
ClientHello + CKE->
<- ACK, ServerHello, etc.
<- Data
Finished ->
Data ->
At which point the situation is the same as tcpcrypt.
> The promised
> improvements to TLS 1.3 don't help: they rely on session caches
> unnecessarily.
I'm not sure what you mean here. The 1RTT handshake for TLS 1.3
does not require session caches, only a relatively restricted set of
ciphers/groups.
-Ekr
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
