Add support for export_keying_material to SSL library

[wingel]

BPO	37952
Nosy	@wingel, @eighthave
PRs	bpo-37952: SSL: add support for export_keying_material #25255

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2019-08-26.08:49:04.430>
labels = ['expert-SSL', 'type-feature', '3.10']
title = 'Add support for export_keying_material to SSL library'
updated_at = <Date 2022-03-20.14:18:50.161>
user = 'https://github.com/wingel'

bugs.python.org fields:

activity = <Date 2022-03-20.14:18:50.161>
actor = 'eighthave'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['SSL']
creation = <Date 2019-08-26.08:49:04.430>
creator = 'wingel71'
dependencies = []
files = []
hgrepos = []
issue_num = 37952
keywords = ['patch']
message_count = 9.0
messages = ['350512', '350513', '350514', '390433', '415553', '415569', '415579', '415585', '415604']
nosy_count = 2.0
nosy_names = ['wingel71', 'eighthave']
pr_nums = ['25255']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue37952'
versions = ['Python 3.10']

[wingel]

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?

[tiran]

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.

[wingel]

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.

[wingel]

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.

[eighthave]

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.

[wingel]

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

---

[tiran]

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.