Agreed on keeping the server side implementation as simplistic as possible. For this particular feature (SPA over HTTP, DNS, or other application protocol), one strategy might be to only compile in this code if enabled via a set of command line arguments to the autoconf configure script (--enable-spa-http, --enable-spa-dns, etc.). That way, most users aren't any worse off since any potentially vulnerable code would not even be compiled into the fwknopd binary by default, and at the same time users that really want this feature have a way to enable it. There are some similar things coming such as the ability to link against OpenSSL directly for encryption/decryption operations, but this would also not be enabled by default. It would just provide a way for users that trust OpenSSL more than the alternative open source Rijndael + digest algorithm code that fwknop uses to have an alternative. This is certainly a trade off though since OpenSSL has a lot more code doing a lot more things that fwknop will ever need, so it's certainly not clear that linking against OpenSSL would provide any security benefit.
While we're on the OpenSSL topic for a bit - one thing that the next fwknop release will do is provide a way for the test suite to verify that SPA packets encrypted with libfko can be decrypted via OpenSSL and vice versa. This provides a way for fwknop to ensure that the crypto operations are compatible with OpenSSL without linking against it directly. This essentially means that fwknop can use the OpenSSL community as a provider of security research. I.e., if a vulnerability is found in OpenSSL that causes them to change their implementation of Rijndael or anything else that fwknop depends on, then fwknop will be able to track this automatically through the test suite. Most of this code is already finished in the hmac_support branch:
I think the libfko routines would largely be the same, but there would need to some additional code to get to the SPA payload data within all supported applications (HTTP, DNS, etc.). It turns out that the client can already send SPA packets over HTTP requests:
But, this functionality is not yet tested through the test suite (will be included before the fwknop-2.5 release):
$ git grep send_spa_packet_http test/test-coverage/
test/test-coverage/iptables/zero_called_functions:../client/spa_comm.c.gcov:function send_spa_packet_http called 0 returned 0% blocks executed 0%