[openssl-users] TLS 1.3 PSK test server setup

Viktor Dukhovni openssl-users at dukhovni.org
Thu Feb 15 16:38:40 UTC 2018



> On Feb 15, 2018, at 10:47 AM, Matt Caswell <matt at openssl.org> wrote:
> 
> TLSv1.3 PSKs are very different to TLSv1.2 PSKs. In TLSv1.3 they are
> effectively the same thing as a session (they are indistinguishable on
> the wire) - and are handled internally by the same logic. As with any
> session the server may or may not choose to use it.

My understanding was somewhat in the other directions, in TLS 1.3 sessions
resumption was reimplemented as a PSK, simplifying the protocol, but this
does not mean that *all* PSKs are ephemeral sessions to be optionally
resumed.  Are there not PSKs that are long-term shared keys?

Do we provide a means to specify one of those and have it be used in
preference to (or to the exclusion of) all other handshake variants?

> If we are talking about the "principle of least surprise" then I would
> find it quite surprising if the server selected a non-preferred
> ciphersuite when a mutually supported better one exists.

Sure, with session resumption, but if a user expects to use a PSK with
some server for mutual authentication via a shared long-term secret, I
would be as surprised if it were not used.

Perhaps the technical similarity of session resumption with PSKs is
contrary to user intent.  The below are not the same:

	* A previously established resumable session
	* A long-term shared key PSK "established out of band"

Note also that perhaps you're thinking primarily about the server,
to which the RFC implementation note applies:

   Implementor's note: the most straightforward way to implement the
   PSK/cipher suite matching requirements is to negotiate the cipher
   suite first and then exclude any incompatible PSKs.  Any unknown PSKs
   (e.g., they are not in the PSK database or are encrypted with an
   unknown key) SHOULD simply be ignored.  If no acceptable PSKs are
   found, the server SHOULD perform a non-PSK handshake if possible.

But my concern is whether a client that specifies intentional use of
an out-of-band shared-key PSK will get its expected behaviour.

-- 
	Viktor.



More information about the openssl-users mailing list