[openssl-users] TLS 1.3 PSK test server setup

[Hubert Kario]

On Thursday, 15 February 2018 16:47:33 CET Matt Caswell wrote:
> On 15/02/18 15:33, Viktor Dukhovni wrote:
> >> On Feb 15, 2018, at 9:57 AM, Matt Caswell <matt at openssl.org> wrote:
> >> 
> >> As pointed out by Hubert in #5378 this is in accordance with the
> >> 
> >> recommendations in the spec:
> >>   "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."
> > 
> > OK, it is "straightforward", but I am not sure it satisfies the
> > principle of least surprise.  So I am asking you what you think
> > users can reasonably expect...
> 
> TLSv1.3 PSKs are very different to TLSv1.2 PSKs. 

they're not, you have two values - identity and a secret. in TLS 1.2 identity 
could be empty, in TLS 1.3 it can't be.

in TLS 1.3 _optionally_ the PSK can have a hash explicitly associated with the 
secret. If a hash is not associated, the default sha-256  is used.

> In TLSv1.3 they are
> effectively the same thing as a session (they are indistinguishable on
> the wire) 

that's not true - static PSKs are distinguished by the obfuscated_ticket_age 
value being 0

> - and are handled internally by the same logic. As with any
> session the server may or may not choose to use it.

that's an implementation detail specific to OpenSSL, and I dare say, very 
unexpected for a user

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

except a server configured in version 1.1.0 to support just PSK will stop 
working as soon as both client and server update to 1.1.1

I'd call that "surprising"

> I suspect that most implementations will follow the advice above from
> the spec, and again it would be quite surprising if we did something
> different. Not only that it would add unnecessary complexity to the
> logic in this area.

I've already talked with Nikos about situation in GnuTLS and it will support 
PSKs transparently in TLS 1.2 and TLS 1.3, configurations won't break.
 
> What is perhaps the source of any "surprise" that a user might
> experience is that TLSv1.2 and TLSv1.3 share the same name for PSKs,
> when really they are only related at a conceptual level: at an
> implementation level they are totally different. Perhaps it would have
> been better if they had been called something different. That is
> slightly unfortunate - but not something we can do much about
> (especially at this late stage).

that's how you see it, and having just implemented support for them, I do not 
agree
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180215/f6bf412b/attachment.sig>