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

[Neetish Pathak]

On Wed, Jul 19, 2017 at 2:27 AM, Matt Caswell <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



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

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.

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.

Thanks
Best regards,
Neetish












> > But then how can that data be read on the client side since
> > read_early_data api is invalid on client side ?
>
> 0.5 RTT data is sent from the server to an unauthenticated client. At
> this point in the process the server has sent all of its messages
> (including its Certificate/CertificateVerify/Finished messages) but it
> has not received the Client Finished or any client
> Certificate/CertificateVerify if one is going to be sent.
>
> From the client's perspective 0.5 RTT data is received *after* it has
> processed the server's Certificate/CertificateVerify/Finished messages),
> and after it has sent its own Finished (and
> Certificate/CertificateVerify if appropriate). In other words from the
> client's perspective the server is fully authenticated and 0.5 RTT data
> is indistinguishable from post-handshake data. Just use SSL_read() as
> normal to receive it.
>
> Matt
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170724/3a768b7d/attachment-0001.html>