Re: [Fwd: Re: [Fwd: Re: Thoughts on Camillia in openssl binaries?]]
William A. Rowe, Jr. wrote: Feedback from Ben via legal-discuss, since his httpd-dev list seems to have fallen over and can't get up. Bill Subject: Re: [Fwd: Re: Thoughts on Camillia in openssl binaries?] From: Ben Laurie [EMAIL PROTECTED] Date: Thu, 20 Sep 2007 10:28:57 +0100 To: William A. Rowe, Jr. [EMAIL PROTECTED] To: William A. Rowe, Jr. [EMAIL PROTECTED] CC: ASF Legal Discuss [EMAIL PROTECTED] William A. Rowe, Jr. wrote: A thread from [EMAIL PROTECTED], we are considering adding a newer algorithm to a binary 0.9.8 build of openssl. Introduces a patent question, with what is almost but not quite a complete grant of license. Looking for any feedback if this would concern us, since Tom raises the point that it gets interesting with Firefox 3 possibly using this algorithm. I should point out that just because some loon contributes an algorithm to OpenSSL doesn't mean you need to implement it. If there's any encumbrance, then I see even less reason to implement (less than none, that is). The Japanese export restrictions apply to all algorithms (including the current ones), not just Camellia. Camellia itself imposes no additional restrictions. Camellia is in RFC4132, and is recommended by the by the EU NESSIE and the Japanese CRYPTREC organizations - but not by any U.S. organizations (...that I know of...) Perhaps Ben meant some loons (plural). Unfortunately, there is no word for groups of loons, as with gaggle of geese etc. -tom-
Re: Thoughts on Camillia in openssl binaries?
On 9/20/07, William A. Rowe, Jr. [EMAIL PROTECTED] wrote: Tom Donovan wrote: William A. Rowe, Jr. wrote: But if mod_deflate doesn't use it, and openssl is built zlib-dynamic, they simply pitched compression from ssl sessions as well with no other adverse effects. Yes, exactly. openssl doesn't select gzip compression if zlib-dynamic and zlib1.dll is missing. The other aspect, if a zlib1.dll replacement is needed for some critical decryption flaw in zlib again, it will be nice not to force users to entirely replace openssl or mod_deflate. So I expect we'll leave it as-is. I think mod_deflate on Windows links statically (zlib.lib) while openssl is linked dynamically (zdll.lib). At 40-60kb it's no big deal either way - but the security flaw in zlib argument would seem to apply to both equally. Both static or both dynamic would be more consistent. You were right, we weren't linking to zdll.lib for mod_deflate, I'll be fixing that shortly, and working up the two patches to share, one for the APR_NO_FILE tweak, one for the stderr quirk with modperl. Had to push out these binaries first, and also now am struggling very deep inside MSVCR80/OpenSSL/ActiveState Perl on x64 and a host of bugs that some of the perl packages have, assuming they can pack pointers into int's and back out again. Sorry that mess left me distracted from the issues you raised for most of this week. I found ActivePerl to not work to well on x64... I compiled the original perl source with MSVC70 and it works ok with extensions compiled with MSVC80... I never manged to get perl itself on MSVC80. I had no luck with ActiveState Perl. Bill -- ~Jorge
RE: Thoughts on Camillia in openssl binaries?
Perl 5.9.5 contains numerous changes to support building with MSVC80. These changes will be in 5.8.9 when that gets released, but 5.10 is looking distinctly likely to be released before it (and, of course, will also contain the changes). Steve From: Jorge Schrauwen [mailto:[EMAIL PROTECTED] Sent: 20 September 2007 09:37 To: dev@httpd.apache.org Subject: Re: Thoughts on Camillia in openssl binaries? I found ActivePerl to not work to well on x64... I compiled the original perl source with MSVC70 and it works ok with extensions compiled with MSVC80... I never manged to get perl itself on MSVC80. I had no luck with ActiveState Perl. -- ~Jorge
[Fwd: Re: [Fwd: Re: Thoughts on Camillia in openssl binaries?]]
Feedback from Ben via legal-discuss, since his httpd-dev list seems to have fallen over and can't get up. Bill ---BeginMessage--- William A. Rowe, Jr. wrote: A thread from [EMAIL PROTECTED], we are considering adding a newer algorithm to a binary 0.9.8 build of openssl. Introduces a patent question, with what is almost but not quite a complete grant of license. Looking for any feedback if this would concern us, since Tom raises the point that it gets interesting with Firefox 3 possibly using this algorithm. I should point out that just because some loon contributes an algorithm to OpenSSL doesn't mean you need to implement it. If there's any encumbrance, then I see even less reason to implement (less than none, that is). Bill Subject: Re: Thoughts on Camillia in openssl binaries? From: Tom Donovan [EMAIL PROTECTED] Date: Tue, 18 Sep 2007 16:19:55 -0400 To: dev@httpd.apache.org To: dev@httpd.apache.org William A. Rowe, Jr. wrote: Two questions, one technical one legal. Technically, do we want to enable the Camillia algorithms in our binary builds of openssl 0.9.8 for win32 and other platforms where we might build it? Legally are we satisfied by http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html ? There is a small clause about permission needed to export from JP, which would mean if a JP site redistributed our binary (e.g. reexported it) it might cause them a hassle. Bill Seems reasonable in anticipation of it becoming supported in FireFox 3. FYI - enabling camellia works well with Apache 2.2.4/mod_ssl on Windows to the NTT test site - https://info.isl.ntt.co.jp/crypt/eng/camellia. The selected Cipher Suite is TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA. On a slightly-related note; it might also be a good change to statically link zlib into OpenSSL to avoid the need for zlib1.dll. Doing so adds about 40kb to the size of libeay32.dll vs. shipping the 58kb zlib1.dll. I think rle compression (which is always available) or no-compression gets used for SSL in most cases anyway. Many Windows users delete zlib1.dll and never notice its absence. PERL Configure VC-WIN32 enable-camellia zlib --with-zlib-lib=../zlib/zlib.lib --with-zlib-include=../zlib -tom- - DISCLAIMER: Discussions on this list are informational and educational only. Statements made on this list are not privileged, do not constitute legal advice, and do not necessarily reflect the opinions and policies of the ASF. See http://www.apache.org/licenses/ for official ASF policies and documents. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff ---End Message---
Re: Thoughts on Camillia in openssl binaries?
Very interesting I'll keep and eye out for 5.10... Now back on topic... On 9/20/07, Steve Hay [EMAIL PROTECTED] wrote: Perl 5.9.5 contains numerous changes to support building with MSVC80. These changes will be in 5.8.9 when that gets released, but 5.10 is looking distinctly likely to be released before it (and, of course, will also contain the changes). Steve -- *From:* Jorge Schrauwen [mailto:[EMAIL PROTECTED] *Sent:* 20 September 2007 09:37 *To:* dev@httpd.apache.org *Subject:* Re: Thoughts on Camillia in openssl binaries? I found ActivePerl to not work to well on x64... I compiled the original perl source with MSVC70 and it works ok with extensions compiled with MSVC80... I never manged to get perl itself on MSVC80. I had no luck with ActiveState Perl. -- ~Jorge -- ~Jorge
Re: Thoughts on Camillia in openssl binaries?
Tom Donovan wrote: William A. Rowe, Jr. wrote: But if mod_deflate doesn't use it, and openssl is built zlib-dynamic, they simply pitched compression from ssl sessions as well with no other adverse effects. Yes, exactly. openssl doesn't select gzip compression if zlib-dynamic and zlib1.dll is missing. The other aspect, if a zlib1.dll replacement is needed for some critical decryption flaw in zlib again, it will be nice not to force users to entirely replace openssl or mod_deflate. So I expect we'll leave it as-is. I think mod_deflate on Windows links statically (zlib.lib) while openssl is linked dynamically (zdll.lib). At 40-60kb it's no big deal either way - but the security flaw in zlib argument would seem to apply to both equally. Both static or both dynamic would be more consistent. You were right, we weren't linking to zdll.lib for mod_deflate, I'll be fixing that shortly, and working up the two patches to share, one for the APR_NO_FILE tweak, one for the stderr quirk with modperl. Had to push out these binaries first, and also now am struggling very deep inside MSVCR80/OpenSSL/ActiveState Perl on x64 and a host of bugs that some of the perl packages have, assuming they can pack pointers into int's and back out again. Sorry that mess left me distracted from the issues you raised for most of this week. Bill
Thoughts on Camillia in openssl binaries?
Two questions, one technical one legal. Technically, do we want to enable the Camillia algorithms in our binary builds of openssl 0.9.8 for win32 and other platforms where we might build it? Legally are we satisfied by http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html ? There is a small clause about permission needed to export from JP, which would mean if a JP site redistributed our binary (e.g. reexported it) it might cause them a hassle. Bill
Re: Thoughts on Camillia in openssl binaries?
William A. Rowe, Jr. wrote: Two questions, one technical one legal. Technically, do we want to enable the Camillia algorithms in our binary builds of openssl 0.9.8 for win32 and other platforms where we might build it? Legally are we satisfied by http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html ? There is a small clause about permission needed to export from JP, which would mean if a JP site redistributed our binary (e.g. reexported it) it might cause them a hassle. Bill Seems reasonable in anticipation of it becoming supported in FireFox 3. FYI - enabling camellia works well with Apache 2.2.4/mod_ssl on Windows to the NTT test site - https://info.isl.ntt.co.jp/crypt/eng/camellia. The selected Cipher Suite is TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA. On a slightly-related note; it might also be a good change to statically link zlib into OpenSSL to avoid the need for zlib1.dll. Doing so adds about 40kb to the size of libeay32.dll vs. shipping the 58kb zlib1.dll. I think rle compression (which is always available) or no-compression gets used for SSL in most cases anyway. Many Windows users delete zlib1.dll and never notice its absence. PERL Configure VC-WIN32 enable-camellia zlib --with-zlib-lib=../zlib/zlib.lib --with-zlib-include=../zlib -tom-
Re: Thoughts on Camillia in openssl binaries?
Tom Donovan wrote: William A. Rowe, Jr. wrote: Two questions, one technical one legal. Technically, do we want to enable the Camillia algorithms in our binary builds of openssl 0.9.8 for win32 and other platforms where we might build it? Legally are we satisfied by http://info.isl.ntt.co.jp/crypt/eng/info/chiteki.html ? There is a small clause about permission needed to export from JP, which would mean if a JP site redistributed our binary (e.g. reexported it) it might cause them a hassle. Bill Seems reasonable in anticipation of it becoming supported in FireFox 3. Yes, that seems like a measurable target. It's nice to be ahead of the curve. FYI - enabling camellia works well with Apache 2.2.4/mod_ssl on Windows to the NTT test site - https://info.isl.ntt.co.jp/crypt/eng/camellia. The selected Cipher Suite is TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA. Good to know, thanks! On a slightly-related note; it might also be a good change to statically link zlib into OpenSSL to avoid the need for zlib1.dll. Doing so adds about 40kb to the size of libeay32.dll vs. shipping the 58kb zlib1.dll. Are you factoring in the cost of statically linking it also to mod_deflate? Consider also anyone using either the compression or decompression side of zlib1.dll from perl/mod_perl, php, python etc. You know from my deployment of awk.exe for the installer that I'm pretty intolerant of bloat, I think rle compression (which is always available) or no-compression gets used for SSL in most cases anyway. Many Windows users delete zlib1.dll and never notice its absence. Well people who randomly delete dll's certainly get what they ask for, we install it in the httpd/bin tree, not on their system32 or somewhere equally offensive. But if mod_deflate doesn't use it, and openssl is built zlib-dynamic, they simply pitched compression from ssl sessions as well with no other adverse effects. PERL Configure VC-WIN32 enable-camellia zlib --with-zlib-lib=../zlib/zlib.lib --with-zlib-include=../zlib FYI the ASF's build hard-links it this way (zdll.lib instead) which ensures we throw away the zlib-dynamic stubs (and eliminate some race and processing-time performance hits), so there is that factor, too. I sort of doubt we'll see any savings when you factor deflate and openssl together? The other aspect, if a zlib1.dll replacement is needed for some critical decryption flaw in zlib again, it will be nice not to force users to entirely replace openssl or mod_deflate. So I expect we'll leave it as-is.
Re: Thoughts on Camillia in openssl binaries?
William A. Rowe, Jr. wrote: But if mod_deflate doesn't use it, and openssl is built zlib-dynamic, they simply pitched compression from ssl sessions as well with no other adverse effects. Yes, exactly. openssl doesn't select gzip compression if zlib-dynamic and zlib1.dll is missing. The other aspect, if a zlib1.dll replacement is needed for some critical decryption flaw in zlib again, it will be nice not to force users to entirely replace openssl or mod_deflate. So I expect we'll leave it as-is. I think mod_deflate on Windows links statically (zlib.lib) while openssl is linked dynamically (zdll.lib). At 40-60kb it's no big deal either way - but the security flaw in zlib argument would seem to apply to both equally. Both static or both dynamic would be more consistent. -tom-
Re: Thoughts on Camillia in openssl binaries?
Tom Donovan wrote: William A. Rowe, Jr. wrote: The other aspect, if a zlib1.dll replacement is needed for some critical decryption flaw in zlib again, it will be nice not to force users to entirely replace openssl or mod_deflate. So I expect we'll leave it as-is. I think mod_deflate on Windows links statically (zlib.lib) while openssl is linked dynamically (zdll.lib). At 40-60kb it's no big deal either way - but the security flaw in zlib argument would seem to apply to both equally. Both static or both dynamic would be more consistent. This was 2.0 that compiled in the subset of zlib sources directly. 2.2 should (and I'll fix this if I'm wrong) be linked to zlib1.dll
