<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
[Matt's reply is likely to be high latency]<br>
<br>
On 07/24/2017 08:53 PM, Neetish Pathak wrote:<br>
<blockquote type="cite"
cite="mid:CANWFjKBCetikoMDx=hmnHvZT-Ufguw04cBmkbeAaU-Y-2sLGQA@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jul 19, 2017 at 2:27 AM, Matt
Caswell <span dir="ltr"><<a
href="mailto:matt@openssl.org" target="_blank"
moz-do-not-send="true">matt@openssl.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><span class="gmail-"><br>
<br>
On 18/07/17 22:27, Neetish Pathak wrote:<br>
> Hi ,<br>
> thanks Matt, this is helpful<br>
><br>
><br>
> One more query on how I can enable 0.5 RTT data
from the server side. It<br>
> is mentioned in TLS 1.3 specification. I thought it
can be implemented<br>
> by sending early data from server side after
reading the early data.<br>
<br>
</span>That is correct, and is as documented on this page:<br>
<br>
<a
href="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="
rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.openssl.org/docs/<wbr>manmaster/man3/SSL_write_<wbr>early_data.html</a></blockquote>
<div><br>
</div>
<div><br>
</div>
<div>Thanks Matt</div>
<div>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).</div>
<div>I am performing following steps on client and server
respectively as per understanding developed from previous
discussions</div>
<div><br>
</div>
<div><b>Pseudocode for client</b></div>
<div><b><br>
</b></div>
<div>tcp_connect</div>
<div><br>
</div>
<div>write_early(data)</div>
<div><br>
</div>
<div>ssl_connect</div>
<div><br>
</div>
<div>if(early_data_write_failed){</div>
<div> ssl_write(data)</div>
<div>}</div>
<div><br>
</div>
<div>ssl_read</div>
<div><br>
</div>
<div><br>
</div>
<div><b>Pseudocode for server</b></div>
<div><b><br>
</b></div>
<div>tcp_accept</div>
<div><b><br>
</b></div>
<div>read_early{</div>
<div><br>
</div>
<div> if(read_early_success){</div>
<div> write_early(data)</div>
<div> }</div>
<div>}</div>
<div><br>
</div>
<div>ssl_accept</div>
<div><br>
</div>
<div>if(read_early_fail){</div>
<div> ssl_read</div>
<div> ssl_write(data)</div>
<div>}</div>
<div><br>
</div>
<div><br>
</div>
<div>I am measuring latency on the <b>client side</b> from
TCP connection start till it completes the read (ssl_read
returns) (analogues to making a request from client and
reading response).</div>
<div>Please suggest what may be going wrong basically with
these queries</div>
<div><br>
</div>
<div>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</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
Maybe I misunderstand the question, but isn't this is just a natural
consequence of the server (mis)behavior in (2)?<br>
<br>
<blockquote type="cite"
cite="mid:CANWFjKBCetikoMDx=hmnHvZT-Ufguw04cBmkbeAaU-Y-2sLGQA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CANWFjKBCetikoMDx=hmnHvZT-Ufguw04cBmkbeAaU-Y-2sLGQA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>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.</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
-Ben<br>
</body>
</html>