[openssl-users] TLS 1.3 PSK test server setup
hkario at redhat.com
Thu Feb 15 18:15:03 UTC 2018
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
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the openssl-users