<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Thanks Ben for your reply</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Jul 25, 2017 at 6:11 AM, Benjamin Kaduk <span dir="ltr"><<a href="mailto:bkaduk@akamai.com" target="_blank">bkaduk@akamai.com</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">
<div bgcolor="#FFFFFF">
[Matt's reply is likely to be high latency]<div><div class="gmail-h5"><br>
<br>
On 07/24/2017 08:53 PM, Neetish Pathak wrote:<br>
<blockquote type="cite">
<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">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-m_-5687419538489936761gmail-"><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">https://www.openssl.org/docs/m<wbr>anmaster/man3/SSL_write_early_<wbr>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></div></div>
Maybe I misunderstand the question, but isn't this is just a natural
consequence of the server (mis)behavior in (2)?</div></blockquote><div><br></div><div><br></div><div>Yes, this is right, the server misbehavior is causing this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-"><br>
<br>
<blockquote type="cite">
<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></span>
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.</div></blockquote><div><br></div><div><br></div><div>I see that the application data is not being sent from server to an unauthenticated client. The server is sending data only after receiving some encrypted message which I believe is the EndOfEarlyData and Finished messages. Following is a dump of wireshark logs for the communication with early data enabled. I also tried with some logs in Openssl libraries, I see early data gets written from server side when write_early_data is called. Internally SSL_write_ex is called which completes write and handshake. But I am not sure why application data is not actually pushed from the server side. It is waiting for the Client finished message. </div><div>I have disabled Nagle's algo during this operation.</div><div><br></div><div>Client port is 56806 and server port is 12345</div><div><br></div><div><br></div><div><div><div>No. Time Source Destination Protocol Length Info</div><div> 207 18.380298 ::1 ::1 TLSv1.3 956 Client Hello <font color="#ff0000"> ----------------- Client Hello</font></div><div><br></div><div><br></div></div><div>No. Time Source Destination Protocol Length Info</div><div> 208 18.380335 ::1 ::1 TLSv1.3 2849 Application Data <font color="#ff0000"> ------------------<font size="4"><b>Early Data from the client side (Intended Application Data)</b></font></font></div><div>Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq: 881, Ack: 1, Len: 2773<br></div><div><br></div><div>No. Time Source Destination Protocol Length Info<br></div><div> 211 18.380624 ::1 ::1 TLSv1.3 219 Server Hello, Application Data, Application Data . <span style="color:rgb(255,0,0)">------------Server Hello and (encrypted handshake message/extensions)</span></div><div>Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 1, Ack: 3654, Len: 143<br></div><div><br></div><div>No. Time Source Destination Protocol Length Info</div><div> 213 18.380819 ::1 ::1 TLSv1.3 160 Application Data, Application Data <font color="#ff0000">------Encrypted handshake msg from client (<font size="4"><b>I believe they are end early data and finished</b></font>)</font></div><div>Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq: 3654, Ack: 144, Len: 84</div><div><br></div><div><br></div><div>No. Time Source Destination Protocol Length Info</div><div> 215 18.381122 ::1 ::1 TLSv1.3 762 Application Data</div><div>Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 144, Ack: 3738, Len: 686 <font color="#ff0000">-----I don't know why this application data is sent from server. My guess is this is session info</font><br></div><div><br></div><div><br></div><div>No. Time Source Destination Protocol Length Info</div><div> 217 18.381210 ::1 ::1 TLSv1.3 9917 Application Data <font color="#ff0000">----------<b><font size="4">Intended Application Data that was intended to be early data </font></b></font></div><div>Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 830, Ack: 3738, Len: 9841</div><div><br></div><div>No. Time Source Destination Protocol Length Info</div><div> 219 18.381308 ::1 ::1 TLSv1.3 100 Application Data . <font color="#ff0000">---------Application Data from client (I also see this application data sent everytime, not sure why)</font></div><div>Transmission Control Protocol, Src Port: 56806, Dst Port: 12345, Seq: 3738, Ack: 10671, Len: 24</div><div><br></div><div><br></div><div>No. Time Source Destination Protocol Length Info</div><div> 220 18.381309 ::1 ::1 TLSv1.3 100 Application Data . <span style="color:rgb(255,0,0)">---------Application Data from server (I also see this application data sent everytime, not sure why)</span></div><div>Transmission Control Protocol, Src Port: 12345, Dst Port: 56806, Seq: 10671, Ack: 3738, Len: 24</div><div><br></div><div>Please provide any comments if you have or how I should go about debugging it. Correct me if I am doing it wrong</div><div><br></div><div><br></div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><span class="gmail-"><br>
<br>
<blockquote type="cite">
<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></span>
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></div></blockquote><div><br></div><div><br></div><div>OK, I understand that, Thanks Ben. I think I got a small improvement on latency by removing TLSEXT_KEX_MODE_KE_DHE. But I also reckon that security comes first and hence it requires deliberation. </div><div> </div><div> Thanks</div><div>BR,</div><div>Neetish</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
<br>
-Ben<br>
</div>
</blockquote></div><br></div></div>