Re: session resumption tls1.2/tls1.3

[Benjamin Kaduk via openssl-users <openssl-users@xxxxxxxxxxx>]

[Matt's reply is likely to be high latency]

On 07/24/2017 08:53 PM, Neetish Pathak wrote:

On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell <matt@xxxxxxxxxxx> wrote:

On 18/07/17 22:27, Neetish Pathak wrote:
> Hi ,
> thanks Matt, this is helpful
>
>
> One more query on how I can enable 0.5 RTT data from the server side. It
> is mentioned in TLS 1.3 specification. I thought it can be implemented
> by sending early data  from server side after reading the early data.

That is correct, and is as documented on this page:

https://www.openssl.org/docs/manmaster/man3/SSL_write_early_data.html

Thanks Matt

To send 0.5 RTT data I m sending the early_data from the server side just after the early_read data. But when I see the wire-shark logs, I see that the server data is sent only once the complete handshake has taken place. (which is the same as using SSL_write after SSL_accept).

I am performing following steps on client and server respectively as per understanding developed from previous discussions

Pseudocode for client

tcp_connect

write_early(data)

ssl_connect

if(early_data_write_failed){

      ssl_write(data)

}

ssl_read

Pseudocode for server

tcp_accept

read_early{

     if(read_early_success){

          write_early(data)

      }

}

ssl_accept

if(read_early_fail){

    ssl_read

    ssl_write(data)

}

I am measuring latency on the client side from TCP connection start  till it completes the read (ssl_read returns) (analogues to making a request from client and reading response).

Please suggest what may be going wrong basically with these queries

1) Why is there no difference (or negligible) in latencies when i use early write and then later ssl_read compared to when I execute normal write/read on the client side

Maybe I misunderstand the question, but isn't this is just a natural consequence of the server (mis)behavior in (2)?

2) Why does the server not send data (for early write) after the server Hello(and other encrypted message) message even when early_write succeeds on server side. Why does server wait to finish the handshake. I know it waits because I see client sending encrypted messages after server hello message before my intended application data gets sent from server. These encrypted messages from the client side are the usual messages from the client side for handshake completion.

From a quick look through the state machine code, this is supposed to work.  But someone would probably have to instrument the code (e.g., with printf) to tell why the delay is being introduced.  I don't think I have the availability to do so in the near future, myself.

3) Also, the performance of TLS 1.3 using early data or resumption is worse than TLS 1.2 resumption on LAN. I see on wire-shark that encrypted messages get exchanged in TLS 1.3 during handshake which are plaintext in TLS 1.2. I think that causes extra latency. So can we say that TLS 1.3 resumption is not recommended for LAN for performance enhancement when compared with TLS 1.2 resumption. On WAN, I see TLS 1.3 resumption at par with TLS 1.2 resumption and full handshake better for TLS 1.3.

It seems like it hasn't really sunk in for you that TLS 1.3 is a seriously different protocol than TLS 1.2, and it provides stronger security properties, remediating weaknesses of TLS 1.2.  So no, we should not recommend TLS 1.2 resumption on the LAN -- we should recommend the more secure option!  If you continue to believe that latency trumps everything else, you could experiment with SSL_OP_ALLOW_NO_DHE_KEX to cut out some of the heavier-weight asymmetric crypto, though it looks like you'd want to patch ssl/statem/extensions_clnt.c to not send TLSEXT_KEX_MODE_KE_DHE, as I don't see a way to configure the server to prefer the non-DHE PSK key exchange.

-Ben

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users