<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 06/19/2017 04:12 PM, Neetish Pathak wrote:<br>
<blockquote type="cite"
cite="mid:CANWFjKD4kA0NBAp8H8n32PPrdSDfNw1U==H1Mj5U-wM=J7p3TQ@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 Mon, Jun 19, 2017 at 11:11 AM,
Neetish Pathak <span dir="ltr"><<a
href="mailto:npathak2@ncsu.edu" target="_blank"
moz-do-not-send="true">npathak2@ncsu.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Matt,
<div>Thanks</div>
<div>Could you help with following queries</div>
<div><br>
</div>
<div>1) <span style="font-size:12.8px">On the blogpost
for TLS1.3, you mentions the following in the
session section</span></div>
<span class="">
<div style="font-size:12.8px"><span
style="font-family:"PT
Serif",Georgia,Times,"Times New
Roman",serif;font-size:18.4px;background-color:rgb(248,248,248)">The
specification recommends that applications only
use a session once (although this is not
enforced). For this reason some servers send
multiple session messages to a client. To enforce
the “use once” recommendation applications could
use </span><code style="padding:0px
0.3em;border:1px solid
rgb(221,221,221);font-family:Menlo,Monaco,"Andale
Mono","lucida
console","Courier
New",monospace;line-height:1.5em;font-size:0.8em;vertical-align:baseline;display:inline-block;color:rgb(85,85,85);border-radius:0.4em">SSL_CTX_remove_session()</code><span
style="font-family:"PT
Serif",Georgia,Times,"Times New
Roman",serif;font-size:18.4px;background-color:rgb(248,248,248)"> t<wbr>o
mark a session as non-resumable (and remove it
from the cache) once it has been used.</span><br>
</div>
<div style="font-size:12.8px"><span
style="font-family:"PT
Serif",Georgia,Times,"Times New
Roman",serif;font-size:18.4px;background-color:rgb(248,248,248)"><br>
</span></div>
<div style="font-size:12.8px"><span
style="background-color:rgb(248,248,248)"><font
face="PT Serif, Georgia, Times, Times New Roman,
serif">I am a bit confused here as to why "use
once" is recommended. How will resumption be
ensured then ? I get a PSK in first connection
and use it again for all the other connections.</font></span></div>
<div style="font-size:12.8px"><span
style="background-color:rgb(248,248,248)"><font
face="PT Serif, Georgia, Times, Times New Roman,
serif"><br>
</font></span></div>
</span></div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
"use once" is recommended in a limited circumstance, to prevent an
attacker listening on the network from associating the (multiple)
resumed sessions as being derived from the initial session.<br>
This is a new possibility in TLS 1.3, since in TLS 1.2 the session
ticket was given to the client in cleartext (and presented back to
the server in cleartext), so all uses of the ticket were traceable
back to the original connection and linkable to each other.<br>
<br>
Using a given ticket more than once in TLS 1.3 just brings things
back to basically the TLS 1.2 state in terms of linkability; it's
not a catastrophic failure or anything like that.<br>
<br>
<blockquote type="cite"
cite="mid:CANWFjKD4kA0NBAp8H8n32PPrdSDfNw1U==H1Mj5U-wM=J7p3TQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Jun 19, 2017 at
5:49 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:0 0
0 .8ex;border-left:1px #ccc
solid;padding-left:1ex"><span><br>
</span></blockquote>
</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes Matt, when I switch to remote machines and test my
application programs, I see that TLS 1.3 is faster than
TLS 1.2 in the first connection (around same time as
resumption time in TLS 1.2) itself and there is marginal
or no improvement in the subsequent connections even on
using resumption. Does this mean that resumption in TLS
1.3 is bringing not much benefit in terms of latency. It
makes sense because round trips count for resumption or no
resumption is 1 in TLS 1.3. </div>
<div><br>
</div>
<div>The only benefit with resumption is that the client can
now send zero-RTT data. (early data). However, if we
consider the overall latency in handshake, it is going to
be the same equivalent to 1 round trip.</div>
<div>Is my understanding correct ?</div>
<div><br>
</div>
<div>Is there any way to enable early data or it gets
activated by default once the pre-shared keys are
available at both the client and server ends ?</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
No no no no no, many times no.<br>
You really must not blindly enable early data without a proper
protocol analysis to determine what would happen if an attacker
replayed the early data millions of times, as is possible with the
current TLS 1.3 draft specification. There are a lot of ways to
hurt yourself and your users with it, and I strongly recommend
against trying to enable it just because it looks faster.<br>
(There are separate APIs from the normal read/write APIs to use
early data, to make you explicitly think about whether it's safe
when adding support to an application.)<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CANWFjKD4kA0NBAp8H8n32PPrdSDfNw1U==H1Mj5U-wM=J7p3TQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>I believe session resumption as a concept doesn't hold
that much value from TLS 1.3 onwards since 1-RTT is
directly achieved in TLS 1.3 first connection. Do you
agree?</div>
<br>
</div>
</div>
</div>
</blockquote>
<br>
No. Resumption saves on transferring (and validating!) certificates
and can be done without incurring the cost of an additional
diffie-hellman exchange, among other things.<br>
<br>
-Ben<br>
</body>
</html>