[dev] Updating internal crypto implementation

Fri Jun 2 15:12:40 UTC 2023

With OpenSSL 3.0+, the license is no longer an issue. Of course we still 
support a wide of older platforms where OpenSSL 3.0 isn't available out 
of the box.

I don't see a good reason why one would write/maintain their own crypto 
functions when libraries are available.

I can't think of a better option than OpenSSL when it comes to wide 
availability on systems we care about.

--Jafar

On 6/1/23 08:27, Ward, David - 0665 - MITLL wrote:
>
> I was actually intentionally vague, because I was first trying to 
> elicit history, opinions, etc. about the current state of things.
>
> In particular:
>
>   * Am I correct in understanding the background behind OpenSSL and
>     Zebra/Quagga/FRR? Is it believed that licensing issues which
>     prevented redistribution in the past are resolved now?
>   * Is there a common expectation as to whether FRR is generally built
>     with, or without, OpenSSL linkage today? (Distribution packaging
>     varies: for example in Fedora this build flag is enabled, but in
>     Debian it is disabled.)
>   * Are there strong feelings for or against having cryptographic
>     algorithms embedded in the FRR source code? (Faster execution by
>     using a specific implementation; larger security footprint to be
>     concerned with monitoring within this project; easier to build and
>     port FRR to other platforms by reducing the number of external
>     dependencies; trickier to avoid potential function name collisions
>     between FRR and system libraries; etc.)
>   * Are there strong feelings for or against the use of OpenSSL
>     specifically in FRR today? (It’s a widely installed dependency of
>     other software; it’s overkill for the very limited degree to which
>     FRR uses it; it is likely to be ported to platforms that other
>     libraries are not; it has a more involved API that has changed
>     over time; etc.)
>
> (So far it seems like – all other things being equal – there would 
> generally be a preference against embedding and maintaining these 
> algorithms in FRR.)
>
> Thanks,
>
> David
>
> *From:* Donald Sharp <donaldsharp72 at gmail.com>
> *Sent:* Thursday, June 1, 2023 7:20 AM
> *To:* Christian Hopps <chopps at chopps.org>
> *Cc:* Ward, David - 0665 - MITLL <david.ward at ll.mit.edu>; 
> dev at lists.frrouting.org
> *Subject:* Re: [dev] Updating internal crypto implementation
>
> In theory, I am more than happy with having more security options in 
> FRR, especially if some generic functions we are using can be taken 
> out of FRR and the code maintenance can be taken care of by some other 
> library.
>
> I guess where I have been hesitating to respond is the sentence `Can 
> we update...`.  I am not sure if I should read the sentence as either:
>
> a) David Ward is saying I will do the work to update this code
>
> b) The we implies that someone should just pick this up from the 
> community and run with the idea.
>
> If (a) then I say go for it, David! For this work, though, I would 
> want to see a plan of action for how this is going to be done in the 
> code base. Mainly so that the 2-3 people within the FRR community who 
> really really care about how this is done won't come back and say do 
> it completely differently and your and our time is not wasted.
>
> if (b) then I say that's a great idea! Unfortunately due to how open 
> source development is done, until some business has a use case for 
> this expanded functionality, this idea is going to languish.
>
> Finally if you are going to do option (a), please feel free to 
> privately send me email( or come talk to us on slack ) and we can get 
> the ball rolling on helping you get the work done.
>
> thanks!
>
> donald
>
> On Thu, Jun 1, 2023 at 6:31 AM Christian Hopps <chopps at chopps.org> wrote:
>
>
>     Hi David,
>
>     Add "Is there someone will to do the work and maintain the code?"
>     to the non-library options. The answer to that q. very well could
>     be "no" in which case the library is definitely the way to go. :)
>
>     Thanks,
>     Chris.
>
>     "Ward, David - 0665 - MITLL" <david.ward at ll.mit.edu> writes:
>
>     > FRR has an "internal" implementation of the MD5 and SHA-256
>     algorithms,
>     > including HMAC functions for both. [1] This code is under a BSD
>     license, and
>     > provides an alternative to linking FRR against OpenSSL, for
>     which there were
>     > historical (?) issues around GPL incompatibility. Several
>     routing protocols use
>     > one of these hash algorithms.
>     >
>     > ospf6d was extended last year to support the OSPFv3
>     Authentication Trailer (RFC 7166), which may use any of
>     HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA-512. [2] The
>     choice of algorithm is limited unless FRR has been compiled with
>     OpenSSL support.
>     >
>     > Can we update FRR's internal crypto implementation in order to
>     overcome this limitation? For example:
>     > * Gnulib provides a drop-in version of each of the algorithms
>     mentioned above for inclusion in open-source projects, available
>     under LGPL 2.1.
>     > * FreeBSD has adapted Colin Percival's SHA-256 implementation to
>     support the other SHA-2 algorithms (but without the HMAC functions
>     - which would seem straightforward to adapt).
>     > * Or should FRR rely on an external library for these functions
>     instead? Should it allow the use of something other than OpenSSL,
>     such as Libgcrypt?
>     >
>     > Thanks in advance,
>     >
>     > David
>     >
>     >
>     > [1] The SHA-256 implementation was written by Colin Percival,
>     originally for FreeBSD. His current version seems to be here:
>     > https://github.com/Tarsnap/libcperciva/blob/master/alg/sha256.c
>     >
>     > [2] ospf6d also supports the use of HMAC-MD5 here, despite this
>     not being specified in RFC 7166.
>
>
> _______________________________________________
> dev mailing list
> dev at lists.frrouting.org
> https://lists.frrouting.org/listinfo/dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20230602/088871c5/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4885 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.frrouting.org/pipermail/dev/attachments/20230602/088871c5/attachment.bin>