Please Review: required security algorithms for Java SE 7 implementations

[Sean Mullan]

On 12/16/2010 11:30 AM, Florian Weimer wrote:
> * Sean Mullan:
>
>> On 12/15/10 10:38 AM, Florian Weimer wrote:
>>> * Sean Mullan:
>>>
>>>> Please review the following list:
>>>> http://cr.openjdk.java.net/~mullan/5001004/review.00/StandardNames.html#impl
>>>
>>> "SHA-1" or "SHA1"?  (Our code uses "SHA1" for some reason, perhaps for
>>> consistency with "HmacSHA1".)
>>
>> "SHA-1" is the standard name, but Oracle's implementation (and
>> probably most others) also accept "SHA1" as an alias.
>
> Oh, and I just realized that MD5 and HmacMD5 are missing.  These
> algorithms are still heavily used (and HmacMD5 is not really broken,
> it's only guilty by association).

Yes, MD5 is still in use, but I think it is decreasing in use 
significantly. Can you give more rationale, for example data that would 
suggest that not making these algorithms a requirement would affect a 
significant number of Java applications or where SHA-1/HmacSHA1 would 
not be an adequate alternative?

Also, just FYI but we have no plans to remove support for MD5 and 
HmacMD5 from OpenJDK.

>>> I think the TLSv1 cipher suite list is effectively much longer.
>>> Correct?
>>
>> Yes, but only TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA is mandatory. See
>> section 9 of RFC 2246: http://www.ietf.org/rfc/rfc2246.txt
>
> I think it's prudent to require TLS_RSA_WITH_AES_128_CBC_SHA as well
> (which is mandatory per RFC 5246).  And RFC 5746 support should be
> required, too (which includes TLS_EMPTY_RENEGOTIATION_INFO_SCSV).

TLS_RSA_WITH_AES_128_CBC_SHA is not listed because we did not specify 
that TLS 1.1 or TLS 1.2 should be requirements. TLS 1.1 and 1.2 are new 
features of JDK 7 and AFAIU are not as widely used as TLS 1.0 yet.

Brad, can you comment on the RFC 5746 support? Do you think we should 
make the TLS_EMPTY_RENEGOTIATION_INFO_SCSV CipherSuite a requirement of 
all Java 7 TLS 1.0 implementations?

>>> There should also be some sort of factory to obtain the predefined
>>> algorithms.  Instantiation through the framework is quite slow.  For
>>> message digests, we currently rely on cloning a prototype object of
>>> the appropriate digest.
>>
>> There aren't any plans to add something like this for JDK 7, but
>> perhaps we can consider it for JDK 8. If you could sketch out a few
>> more details of what you think the API would look like, that would
>> help.
>
> Basically, I'd like to have a class which provides reasonable default
> implementations for common mandatory algorithms, without having to go
> through SPIs etc.  That is, a class which implements an interface like
> this:
>
> interface DefaultMessageDigests {
>    MessageDigest newMD5();
>    MessageDigest newSHA1();
>    MessageDigest newSHA256();
> }
>
> For other types of primitives, this may make less sense because they
> generally have tweakable parameters.

Maybe we could do something like that, although I would also like to 
understand the SPI issues better and see if we could look at ways of 
reducing that overhead without coming with new APIs.

--Sean