Thanks Ben for all the replies and your comments. They are extremely useful for my study
On Mon, Jun 19, 2017 at 9:21 PM, Benjamin Kaduk <bka...@akamai.com> wrote: > On 06/19/2017 04:12 PM, Neetish Pathak wrote: > > > > On Mon, Jun 19, 2017 at 11:11 AM, Neetish Pathak <npath...@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 <m...@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.) > > > 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 ? 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. > 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 >
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
