Re: TLS 1.3 PSK test server setup

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

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.

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.

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

I strongly feel this is the correct behaviour.

Matt
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux