[security-dev 01195]: Re: 6840752: Provide out-of-the-box support for ECC algorithms

[Vincent Ryan]

Hello Andrew,

I realize that you, along with others in the Linux community, are less
than satisfied with the changeset to provide out-of-the-box support for
ECC algorithms.

As I mentioned earlier, we were quite constrained in what we could
openly discuss before we pushed. However, now that we have pushed I
am eager to fix any problems that I've introduced.

We wish to reconcile the conflicting demands of including an ECC
implementation for platforms without underlying ECC support with the
exclusion of the ECC implementation on platforms with underlying ECC
support. I'd like to solicit input from security-dev on how best to
achieve this.

Your proposal to supply an NSS config file for the SunPKCS11 provider
is one approach but what about platforms where an ECC-enabled NSS is
not present?



Andrew John Hughes wrote:
> 2009/8/27 Vincent Ryan <Vincent.Ryan at sun.com>:
>> Hello Andrew,
>>
>> Our original intention was to provide a Java implementation of ECC.
>>
>> However due to software patents already granted for ECC we were
>> constrained in what we could reasonably resource and openly discuss.
>>
>> In the end we opted to reuse the NSS code from OpenSolaris (which was
>> originally developed at Sun Labs and donated to OpenSSL and NSS).
>>
>> Although, on many non-Windows platforms, this does result in an existing
>> system library being replicated in the JDK perhaps that issue can be
>> solved in future by making use of modules.
>>
>>
>>
>> Andrew John Hughes wrote:
>>> With this changeset:
>>>
>>> http://hg.openjdk.java.net/jdk7/jdk7/jdk/rev/1ff7163fc5f7
>>>
>>> the new ECC was added to OpenJDK.  When I first read about this, I'd
>>> assumed we were getting a Java-based implementation.  The final
>>> changeset seem to just be an inclusion of the NSS code into the
>>> OpenJDK codebase, which adds yet another case where a system library
>>> is replicated internally (the others being libjpeg, libpng, zlib, lcms
>>> and probably others I've missed).
>>>
>>> Is this correct? Were there local modifications to this code as well?
>>>
>>> As seems to be common practice with OpenJDK, this changeset just
>>> appeared with very little, if any, public discussion.
> 
> Thanks for your reply, Vincent.
> 
> I've now had chance to look at the changeset in more detail, including
> comparing it with the sources from my system NSS, and have a few more
> questions:
> 
>   * Which version of NSS were these sources pulled from?  Running diff
> -bu on them, and ignoring the additional copyright headers,
>   there are still a large number of changes.  I suspect this is
> because the version is older than my system copy (3.12.3); notably my
>   testing shows it does not exhibit the bug discussed in
> http://mail.openjdk.java.net/pipermail/security-dev/2009-September/001167.html
> (which
>   incidentally is still awaiting review).

The sources were pulled from OpenSolaris 2009.06.


>   * Why was a new provider used instead of the existing
> sun.security.pkcs11.SunPKCS11 provider?  I noticed this has not be
> removed, yet
>   it appears to provide duplicate functionality unless I'm mistaken.
> This does perhaps mean we could fix the issues with this changeset
> simply
>   by allowing the ec subdirectory to be turned off, but there may be
> something about the new provider I'm missing.

We introduced the new SunEC provider because we wanted a fast compact
ECC implementation that we could ship on all platforms. We have not
bundled all of NSS - only its ECC implementation.



>   * I notice that a number of algorithms are replaced with NULL.  I
> assume there is some (perhaps legal) reason for this?

Which ones?


> 
> I'm afraid my current impression of this changeset is that it doesn't
> help us with packaging OpenJDK for GNU/Linux distributions at all, but
> instead makes things ten times worse as there is now a stale NSS to
> contend with.  Not only are there the issues with bit rot I alluded to
> last time, but as you mention in your reply there are legal issues
> with EC support.  Notably, I've found that Fedora doesn't ship any EC
> support (https://bugzilla.redhat.com/show_bug.cgi?id=492124) so we'd
> have to rip this out in packages for that distribution (and it's
> dubious whether others should be shipping it).  IANAL, so I won't
> comment further on such issues, but suffice to say this changeset
> significantly reduces the options for handling NSS support downstream.
>  In contrast, the existing support in 1.6 is almost ideal, once you've
> discovered how it works; the distro packager can choose whether to
> enable support or not and they don't have to worry about rotting
> security code in OpenJDK.  Maybe I'm missing something but this makes
> me think this would have been better as a local addition to Sun's
> proprietary builds rather than adding it to OpenJDK.
> 
> I try to be as positive as I can about the OpenJDK project, but I'm
> sorry to say that changesets like this don't help.  I actually find
> them quite depressing.  As I said in my previous email, there appears
> to have been no discussion of this change; it was merely committed
> with no public review and appeared in b70.  Meanwhile, myself and
> other external contributors have to spend days trying to get replies
> to emails to even get a simple bug fix in (I've lost count of how many
> I still have waiting; there must be at least four or five).  That's
> just not fair and doesn't bode well for a successful community
> project.
> 
> Thanks,