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@xxxxxxxxxxx> 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
Attachment:
signature.asc
Description: This is a digitally signed message part.
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
