[openssl-users] Fwd: PSK generation for TLS 1.3

Fri Jul 7 19:38:06 UTC 2017

I have a query regarding the TLS 1.3 handshake message exchange. Please
provide your comments.

With TLS 1.3, I see that Application Data Protocol message is sent from the
server side and client side (using wireshark) during the handshake. I am
only performing handshake and not doing any read write operations. I see
that servers and clients send application data protocol when doing just
SSL_connect and SSL_accept .

I also know that all the messages post server hello are encrypted in TLS
1.3. So, I am not sure what data gets exchanged
When checking logs for TLS 1.2, I do not see any exchange of Application
Data Protocol which is as expected.

Basically, connection sequence for TLS 1.2 is

*Client Hello*
*Server Hello, Certificate, Server Key Exchange, Certificate Request,
Server Hello Done*
*Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec,
Encrypted Handshake Message (Finished)*
*Change Cipher Spec, Encrypted Handshake Message (Finished)*

but for TLS 1.3, it is
The same is the sequence of messages exchanged when doing a connection
using resumption. I am not sure what application data gets exchanged when
doing TLS 1.3 when I am not doing any read/writes.
>From RFC, I can see that Application Data can be optionally sent at the end
of server Hello but I am not sure what data it is. How can I decrypt the
exchanged data ?
*Client Hello*
*Server Hello, Application Data Protocol from Server*
*Application Data Protocol from Client*
*Application Data Protocol from Server*
*Application Data Protocol from Client*

Also, I observe that resumption connection time for TLS 1.3 using PSK  is
more than resumption time for TLS 1.2 (by 700-800 microseconds). I am
suspecting the exchange of application data and its processing etc
(encryption) is causing the added delay. Could someone please provide any
explanation or point me in the right direction. It is not very clear to me
right now even after seeing the RFC

Thanks

On Thu, Jul 6, 2017 at 11:40 AM, Neetish Pathak <npathak2 at ncsu.edu> wrote:

> Thanks for the detailed explanation Matt
>
> On Tue, Jul 4, 2017 at 1:51 AM, Matt Caswell <matt at openssl.org> wrote:
>
>>
>>
>> On 03/07/17 22:24, Neetish Pathak wrote:
>>
>> > Thanks Matt. This is quite useful.
>> > Just to clarify my understanding based on your comments, OpenSSL code
>> >  and Draft for TLS 1.3/RFC for TLS1.2, please help me with following
>> queries
>> >
>> > 1) So, when using external PSK (by creating the new session file),
>> > client should mandatorily use SSL_CTX_set_psk_use_session_callback
>> while
>> > server should mandatorily use SSL_CTX_set_psk_find_session_casllback.
>> > They both should use a common key (psk_key) to generate the new session
>> > file and this common key is the one shared in advance to both client and
>> > server.
>>
>> Yes, that is correct. If both client and server are OpenSSL then,
>> optionally, they can just share a session file (which contains the key)
>> if that is easier.
>>
>> > From the OpenSSL code, this key is used as char * type. So does
>> > it mean that any pre-decided string can be used as a key and it does not
>> > need any format etc.
>>
>> To me "string" implies NUL terminated printable string. Maybe that's not
>> what you meant. Anyway in that sense "string" is not quite correct. The
>> key is binary data which should be the same length as the hash used for
>> the ciphersuite.
>>
>>
>> > Both client and server create sessions based on the
>> > key and connect based on the created session?
>> > In one of the examples, *strspn*(psk_key, "abcdefABCDEF1234567890") is
>> > used. So, I believe I can use any hex value string of my choice as
>> psk_key.
>>
>> Like I said above - the key is *binary* data. It does not have to be a
>> printable string.
>>
>>
>> > 2) Also, from the man page , I found that PSK are used in TLS1.2 and
>> > lower versions too and SSL_CTX_set_psk_server_callback
>> > and SSL_CTX_set_psk_client_callback are used to set callback there. PSK
>> >  identity and Pre shared key is set there which can be used during the
>> > connection. It is also written that these values are required when using
>> > PSK cipher-suites. So, is my understanding correct that the role of PSK
>> > in version <= TLS1.2 is only for using PSK ciphersuites
>> > (e.g: ECDHE-PSK-AES256-CBC-SHA384)
>>
>> Correct.
>>
>> > and do not have anything to do with
>> > session resumption and thereby do not provide any performance
>> enhancement.
>>
>> They do not have anything to do with session resumption, so you don't
>> see the reduced number of message flights that you get with a resumed
>> handshake. However, PSK ciphersuites in <= TLS1.2 avoid the need to send
>> (and therefore process/validate) Certificate messages which may have
>> performance benefits. If the ciphersuite in use just uses "plain" PSK
>> (i.e. no (EC)DHE or RSA) then a connection can be established without
>> using public-key operations which may also have performance benefits (at
>> the expense of forward secrecy).
>>
>> > Also, this PSK type ciphersuites are no longer valid for TLS 1.3.
>>
>> Correct.
>>
>>
>> Matt
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170707/8e8d83e5/attachment.html>