[openssl-users] TLS 1.3 PSK test server setup

[Matt Caswell]

On 15/02/18 16:38, Viktor Dukhovni wrote:
> 
> 
>> 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?

Yes, this is of course possible. Just make sure any PSKs you have
available on the server are consistent with the hash function in your
preferred ciphersuites. If you don't want a non-long term key selected
then don't prefer a ciphersuite that is incompatible with it. If you
never want the possibility of a non-long term key being used then don't
configure a Certificate on your server.

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

A client can "encourage" the server to select a PSK if it only offers
ciphersuites that are compatible with it. If the server is OpenSSL and
has the PSK available it will use it (because all shared ciphersuites
will be compatible with it).

Matt