> On Feb 15, 2018, at 10:47 AM, Matt Caswell <matt@xxxxxxxxxxx> 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. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
