Add support for the export_keying_material function to the SSL library.

Tested with Python 3.7.4 and Python master branch:

https://github.com/wingel/cpython/tree/export_keying_material-3.7.4
https://github.com/wingel/cpython/tree/export_keying_material-master

Is this the correct format for a patch?  Should I include the automatically generated clinic changes in my patch or not?  What about the "versionadded::" string in the documentation?  Should I include a line like that or does it only generate unneccessary conflicts?  Anything else I need to do?

Could you please explain the purpose of the feature and why you want to expose the interface? What's the use case?

As this is a new feature, Python 3.7 and 3.8 are out of scope.

I'm doing an implementation of the NTS protocol for my customer Netnod:

https://github.com/Netnod/nts-poc-python

NTS is draft RFC on its way to become a standard:

https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

NTS requires the export_keying_material functionality as described in RFC5705.

Basically it's a part of the TLS standard, is used by 10 existing protocols with more on the way.  And I can't implement a NTS key establishment server or client without the function.  That's why I added the functionality and verified that it works both with the stable 3.7.4 release and with the master branch of the cpython repository.

I tested with 3.7.4 first on my machine because that's the release of Python that comes with Ubuntu and I wanted to have as few differences as as possible compared to the distribution version.  I then forward ported the patch to the master branch and verified that my NTS implementation still works with that branch.

OpenSSL has a function to "SSL_export_keying_material" as described in RFC5705.  This functionality is needed to be able to support a bunch of other protocols such as "Network Time Security for the Network Time Protocol" which has now become a proper RFC as RFC8915.  There are half a dozen other RFCs which also use this functionality.

I have written a patch to add support for this function which can be found on github:

https://github.com/wingel/cpython

And it is used in my implementation of the NTS procotol which can also be found on github:

https://github.com/Netnod/nts-poc-python

It would be very nice if mainline Python could support for this function in the future so that I don't have to maintain a patched version of Python for this.

We're working on the HTTP Transport Auth draft (https://www.ietf.org/archive/id/draft-schinazi-httpbis-transport-auth-05.html) in the IETF that also needs this method.  I would really love to see this land, any advice?  If it is just a matter of updating the patch for the current Python, I can probably handle that.

Hi,

unfortunately the maintainer of the openssl library in Python doesn't
want to take my patch.  He says that he doesn't want the burden of
supporting more functions in the API.  I'm a bit frustrated about the
whole situation, I've redone my patch over and over again for at least
six months just to receive no feedback at all and to finally be told
that it was all in vain.  If you add a comment to the merge request
saying that you also need that functionality it might help to change
his mind, but probably not.  But it would show that it's not only me
that would like to be able to use that function.

I have kept my patch up to date up to a few weeks ago so unless
something major has happened it ought to apply fairly cleanly to the
latest mainline branch of python.

https://github.com/wingel/cpython/tree/export_keying_material-master

Usually there will be conflict due to an automatically generated
checksum at the end of the file _ssl.c.h but to get around that, just
skip that part of the patch and rerun "clinic" to regenerate the
checksum.  Here's what I usually do to build and test my patch:

./configure --prefix=/opt/python-master

python3 Tools/clinic/clinic.py -f Modules/_ssl.c
Modules/clinic/_ssl.c.h
make -j24
make install

Regards,
  Christer

On Sat, 2022-03-19 at 14:32 +0000, Hans-Christoph Steiner wrote:
> 
> Hans-Christoph Steiner <hans@eds.org> added the comment:
> 
> We're working on the HTTP Transport Auth draft
> (https://www.ietf.org/archive/id/draft-schinazi-httpbis-transport-auth-05.html
> ) in the IETF that also needs this method.  I would really love to
> see this land, any advice?  If it is just a matter of updating the
> patch for the current Python, I can probably handle that.
> 
> ----------
> nosy: +eighthave
> 
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue37952>
> _______________________________________

Neither venting frustration at my expense nor emotional blackmail is going to increase the likeliness, that I will spend my limited personal time to review a patch for a new feature. Feel free to find another core dev who is willing to land and maintain your patch.

Sorry about the venting, but it is kind of frustrating to spend months
working on something with no feedback just to be told that it all was
for nothing.  But that's how it is.  I'll just keep updating my path
every now and then since I need it anyway and don't want my application
to fall too far behind compared to mainstream Python.

My point is mostly that that export_keying_material is starting to be
used in more IETF RFCs.  The most recent one was accepted just a few
weeks ago.  I think that is a bit of a shame that Python doesn't have
support for that functionality out of the box.  If enough people say
it's useful for them maybe that would influence your decision.

As for the rest of my mail.  Since I am trying to keep my patch sort of
up date, I might as well point to it and explain how to use it. 
Hopefully that will reduce your support burden since it will allow
those who need that functionality to build a Python interpreter on
their own.

I understand the frustrations here, but this is really not a place to vent, since that only harms everyone's interests.  When a core maintainer voices concerns or questions, they need to be addressed.  This goes for any project.

I'll see if I can contribute to https://bugs.python.org/issue43902, that would also work for exporting keying material.