[openssl-users] session resumption tls1.2/tls1.3

[Benjamin Kaduk]

[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 at openssl.org
> <mailto:matt at openssl.org>> 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
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_manmaster_man3_SSL-5Fwrite-5Fearly-5Fdata.html&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=MfCOjAV83u4xGuIMb7VquiUt64_HFf9UC8LY4eIP_oc&s=ZAcBNcJWKTExKYdPPPOxcSr51esghiaZM82tPTLtbHM&e=>
>
>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170725/756d64f7/attachment.html>