Re: [Openvpn-devel] [PATCH] mbedtls: add RFC 5705 keying material exporter support

[Gert D. <ge...@gr...>]

Hi,

On Mon, Nov 11, 2019 at 02:12:04PM +0100, Arne Schwabe wrote:
> Am 11.11.19 um 00:10 schrieb Steffan Karger:
> > Since mbed TLS 2.18, mbed TLS can also implement RFC 5705. As a first
> > step towards using the keying material exporter as a method to generate
> > key material for the data channel, implement the
> > --keying-material-exporter function we already have for OpenSSL also for
> > mbed TLS builds.

I tried to apply this patch today, since I have such a nice ACK on it.

Applying to "master" went smooth, but the resulting code does not
build for me:

../../../openvpn/src/openvpn/ssl_mbedtls.c:91:41: error: 'mbedtls_x509_crt_profile_suiteb' undeclared (first use in this function); did you mean 'openvpn_x509_crt_profile_suiteb'?
   91 | #define openvpn_x509_crt_profile_suiteb mbedtls_x509_crt_profile_suiteb;
      |                                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

this is on Gentoo linux, with Gentoo-provided "mbedtls-2.19.1" (so, 
should qualify as "2.18 or higher") and gcc 9.2.0.


Looking closer, I can see that current "git master" does not compile
on this system either, with the same error message.  Seems I should 
run local tests with mbedtls more often, especially after updating...

mbedtls 2.12.0 on the other Gentoo system (the t_server buildslave, which
actually builds 2 times a week against mbedtls) works, as does mbedtls
2.16.3 on on FreeBSD.

So it seems this is something the mbedtls people broke in 2.19?  

(And, for the record, anything newer than 2.12 is masked in gentoo, I 
just unmasked "give me the latest!" at some point in the past so got 
the fun today...)

Steffan, this will bite you anyway, some day :-) - can you have a look?


(I'll proceed to merge the patch...)


... awww... I think I might have found the underlying issue, trying to
understand the MBEDTLS_VERSION_NUMBER convention...

I see you check for "MBEDTLS_VERSION_NUMBER >= 0x02120000", the comment 
says "from 2.18 up", and the thing Gentoo calls "2.19.1" installs a 
version.h which claims 

version.h:#define MBEDTLS_VERSION_NUMBER         0x02110000
version.h:#define MBEDTLS_VERSION_STRING         "2.17.0"

... but the tarball has the proper defines.  WTF...

Awww...

Gentoo's "mbedtls 2.19.1" also installs "mbedcrypto 2.0.0", which *also*
installs a mbedtls/version.h - and that one is the "2.17.0" one which
ends up in the filesystem.  This might be considered a bug in the
.ebuild file, but I find it amazingly silly to have two packages
who both have a "mbedtls/version.h"...

Ceterum censeo: mbedtls has looked long and hard at LibreSSL version
numbering and decided "we can do this in more exciting ways"...

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             ge...@gr...