<div dir="ltr">Thanks Ben for all the replies and your comments. They are extremely useful for my study<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 19, 2017 at 9:21 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><span>
    On 06/19/2017 04:12 PM, Neetish Pathak wrote:<br>
    <blockquote type="cite">
      
      <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">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>
                  <div style="font-size:12.8px"><span>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>SSL_CTX_remove_session()</code><span> 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><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></span>
    "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">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote"><span>
            <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
              <div class="m_1380550235989651447m_3364703587797143416HOEnZb">
                <div class="m_1380550235989651447m_3364703587797143416h5">
                  <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">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>
            </span><span><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>
          </span></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.)<span><br>
    <br>
    <br></span></div></blockquote><div><font color="#0000ff"><br></font></div><div><font color="#0000ff">The comments give me much food for thought. I am still wondering on  on the possibility for replay attacks when early data is enabled. Sorry, I am new to OpenSSL or TLS and have so many doubts. So, I understood replay attacks are possible as in early data enabled mode, data will go in the cleartext form along with clientHello, so a middleman can look into the data and replay it later. I was thinking if we use some kind of sequence number/ timestamps (as possible solution) to avoid this or it has been implemented in OpenSSL ?</font></div><div><font color="#0000ff">I am using the application for an internal project which is not going to be public. So, I am wondering if it can be used. Nevertheless, your recommendation is duly noted. </font></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><span>
    <blockquote type="cite">
      <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></span>
    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>
  </div>

</blockquote></div><br></div></div>