<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>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. <br>
</p>
<p>I don't see a good reason why one would write/maintain their own
crypto functions when libraries are available.</p>
<p>I can't think of a better option than OpenSSL when it comes to
wide availability on systems we care about.</p>
<p>--Jafar<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 6/1/23 08:27, Ward, David - 0665 -
MITLL wrote:<br>
</div>
<blockquote type="cite"
cite="mid:8bbb0f9205bf43a79677953b4fb6796d@BN2P110MB1730.NAMP110.PROD.OUTLOOK.COM">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}span.EmailStyle20
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0in;}ul
{margin-bottom:0in;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">I was actually intentionally vague, because
I was first trying to elicit history, opinions, etc. about the
current state of things.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In particular:<o:p></o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l1 level1 lfo2">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?<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l1 level1 lfo2">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.)<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l1 level1 lfo2">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.)<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l1 level1 lfo2">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.)<o:p></o:p></li>
</ul>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">(So far it seems like – all other things
being equal – there would generally be a preference against
embedding and maintaining these algorithms in FRR.)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">David<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Donald Sharp
<a class="moz-txt-link-rfc2396E" href="mailto:donaldsharp72@gmail.com"><donaldsharp72@gmail.com></a> <br>
<b>Sent:</b> Thursday, June 1, 2023 7:20 AM<br>
<b>To:</b> Christian Hopps <a class="moz-txt-link-rfc2396E" href="mailto:chopps@chopps.org"><chopps@chopps.org></a><br>
<b>Cc:</b> Ward, David - 0665 - MITLL
<a class="moz-txt-link-rfc2396E" href="mailto:david.ward@ll.mit.edu"><david.ward@ll.mit.edu></a>; <a class="moz-txt-link-abbreviated" href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.org</a><br>
<b>Subject:</b> Re: [dev] Updating internal crypto
implementation<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">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:<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">a) David Ward is saying I will do the
work to update this code<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">b) The we implies that someone should
just pick this up from the community and run with the
idea.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">thanks!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">donald<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Jun 1, 2023 at 6:31 AM
Christian Hopps <<a href="mailto:chopps@chopps.org"
moz-do-not-send="true" class="moz-txt-link-freetext">chopps@chopps.org</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
Hi David,<br>
<br>
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. :)<br>
<br>
Thanks,<br>
Chris.<br>
<br>
"Ward, David - 0665 - MITLL" <<a
href="mailto:david.ward@ll.mit.edu" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">david.ward@ll.mit.edu</a>>
writes:<br>
<br>
> FRR has an "internal" implementation of the MD5 and
SHA-256 algorithms,<br>
> including HMAC functions for both. [1] This code is
under a BSD license, and<br>
> provides an alternative to linking FRR against
OpenSSL, for which there were<br>
> historical (?) issues around GPL incompatibility.
Several routing protocols use<br>
> one of these hash algorithms.<br>
><br>
> 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.<br>
><br>
> Can we update FRR's internal crypto implementation in
order to overcome this limitation? For example:<br>
> * Gnulib provides a drop-in version of each of the
algorithms mentioned above for inclusion in open-source
projects, available under LGPL 2.1.<br>
> * 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).<br>
> * 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?<br>
><br>
> Thanks in advance,<br>
><br>
> David<br>
><br>
><br>
> [1] The SHA-256 implementation was written by Colin
Percival, originally for FreeBSD. His current version
seems to be here:<br>
> <a
href="https://github.com/Tarsnap/libcperciva/blob/master/alg/sha256.c"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">
https://github.com/Tarsnap/libcperciva/blob/master/alg/sha256.c</a><br>
><br>
> [2] ospf6d also supports the use of HMAC-MD5 here,
despite this not being specified in RFC 7166.<o:p></o:p></p>
</blockquote>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.org</a>
<a class="moz-txt-link-freetext" href="https://lists.frrouting.org/listinfo/dev">https://lists.frrouting.org/listinfo/dev</a>
</pre>
</blockquote>
</body>
</html>