[openssl-users] Session Ticket Support in Openssl TLS 1.2

[Benjamin Kaduk]

On 06/19/2017 04:12 PM, Neetish Pathak wrote:
>
>
> On Mon, Jun 19, 2017 at 11:11 AM, Neetish Pathak <npathak2 at ncsu.edu
> <mailto:npathak2 at ncsu.edu>> wrote:
>
>     Hi Matt,
>     Thanks
>     Could you help with following queries
>
>     1) On the blogpost for TLS1.3, you mentions the following in the
>     session section
>     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 |SSL_CTX_remove_session()| to mark a session as non-resumable
>     (and remove it from the cache) once it has been used.
>
>     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.
>

"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.
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.

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.

>
>     On Mon, Jun 19, 2017 at 5:49 AM, Matt Caswell <matt at openssl.org
>     <mailto:matt at openssl.org>> wrote:
>
>
>
> 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. 
>
> 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.
> Is my understanding correct ?
>
> 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 ?
>

No no no no no, many times no.
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.
(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.)


> 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?
>

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.

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170619/d193beff/attachment.html>