Differently named symbols between OpenSSL and RFC

[J Decker]

On Fri, Nov 29, 2019 at 10:16 AM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Thu, Nov 28, 2019 at 04:31:38PM -0800, J Decker wrote:
>
> > from openssl/tls1.h 1.1.1b
> >
> > # define TLSEXT_TYPE_psk_kex_modes               45
>
> This was added in 1.1.1-dev.
>
> > pre_shared_key(41), psk_key_exchange_modes(45), are what the names
> should be
> > based on, and that OpenSSL's definition is also inaccurate
> >
> >  TLSEXT_TYPE_psk_kex_modes
> >  TLSEXT_TYPE_psk
> >
> > instead of 'pre_shared_key' and 'key_exchange_modes'
>
> The TLS RFCs do not define an API, they only define a wire protocol.
>
> Implementations are free to use whatever names they see fit for the
> various RFC
> code-points.  OpenSSL chose to abbreviate "key_exchange" to "kex" and
> "pre_shared_key" to "psk".  The LibreSSL maintainers are free to make
> their own
> choices.
>

Well; since they are the clone of the original, they're not exactly 'free'
to make choices; there are constraints issued by consumers of their
libraries (me) that they should be compatible.  So; Their argument for name
choice is 'RFC' , I thought 'understandable easily' but making it the same
as the RFC allows one to search for information on what that extension
might be.  Looking for 'psk' and 'kex' doesn't lead to related information
very well, which is an argument that OpenSSL should also provide alternate
names which align better with other information about such names...

I looked a while to find those symbols when I initially ran into this
issue; and psk just kept coming back to openssl headers/docs which
themselves don't give very good information about the block.



>
> --
>     Viktor.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20191130/deb35593/attachment-0001.html>