RFR [14] 8214483: Remove algorithms that use MD5, DES, or ECB from security requirements

[Sean Mullan]

Hi Bernd,

On 11/6/19 3:05 PM, Bernd Eckenfels wrote:
> Hello,
> 
> While it is probably a good thing to not use ECB I can imagine you 
> actually need it to implement single-block operations, so I am not sure 
> if it’s a good idea if any general purpose JVM does not provide AES/ECB 
> or RSA/ECB? (Maybe a new raw single block mode instead?)

Hmm, that is a good point, so let me think a bit more about that. 
AES/ECB is also used in the SecureRandom CTR_DRBG mechanism implementation.

> For example TLS1.2 handshakes would need RSA/ECB/NoPadding and AES Key 
> Exchange in smime would need AES/ECB as the primitive.

Do you mean for wrapping the RSA premaster secret? Also, did you mean 
RSA/ECB/PKCS1Padding? RSA/ECB/NoPadding was not a requirement.

> On the other hand, requiring 3DES might really not be a requirement 
> anymore, while at it remove it, also?

I did think about that, but industry-wide deprecation of 3DES is more 
recent than DES. I would like to hold off on that for now until we 
understand the compatibility risk a little better for certain components 
such as Kerberos.

--Sean

> 
> Gruss
> Bernd
> -- 
> http://bernd.eckenfels.net
> ------------------------------------------------------------------------
> *Von:* security-dev <security-dev-bounces at openjdk.java.net> im Auftrag 
> von Sean Mullan <sean.mullan at oracle.com>
> *Gesendet:* Mittwoch, November 6, 2019 5:28 PM
> *An:* security Dev OpenJDK
> *Betreff:* RFR [14] 8214483: Remove algorithms that use MD5, DES, or ECB 
> from security requirements
> Please remove this change to remove the Java SE requirements to
> implement security algorithms based on DES, MD5, or ECB. It makes sense
> to periodically review these requirements and remove algorithms or modes
> that are known to be weak and of which usage has declined significantly
> and thus compatibility risk is much lower.
> 
> Note that we are not removing the actual implementations of these
> algorithms from the JDK. This just means that an SE implementation is
> not required to support these algorithms.
> 
> webrev: https://cr.openjdk.java.net/~mullan/webrevs/8214483/webrev.00/
> CSR: https://bugs.openjdk.java.net/browse/JDK-8233607
> 
> Thanks,
> Sean
>