Code Review Request, JDK-8140436, Support the FFDHE TLS extension

Jamil Nimeh jamil.j.nimeh at oracle.com
Tue Apr 18 04:06:34 UTC 2017


Hi Xuelei, comments in-line:

On 4/17/2017 8:18 PM, Xuelei Fan wrote:
> On 4/17/2017 4:47 PM, Jamil Nimeh wrote:
>> Hi Xuelei, one question and one nit, the rest looks pretty good.
>>
>>   * SupportedGroupsExtension
>>       o Line 267 and 278: From what I can see historically and with TLS
>>         1.3 draft 19 the underlying list for elliptic_curves and/or
>>         supported_groups extension data cannot be empty.  Should there
>>         be guards in the two constructors to prevent use of an empty
>>         array or an incoming empty vector?
> Good catch!
>
> Line 267 is a private constructor.  The caller does not use empty 
> groups (line 356-364).
>
> For the comment for line 278, I added a check in line 274 (see the 
> updated webrev.01):
> -274         if (((len & 1) != 0) || (k + 2 != len)) {
> +274         if (((len & 1) != 0) || (k == 0) || (k + 2 != len)) {
>
> An SSLProtocolException will be thrown if the incoming vector is empty.
Looks good to me.
>
>
>>   * NamedGroup
>>       o This is a nit, but I'm curious why you didn't just overload
>>         valueOf as valueOf(int) and valueOf(String) similar to how
>>         Integer does it and others like it.  I'm fine with it as-is if
>>         you prefer to keep it that way.
>>
> The valueOf(String) is a builtin method of Java enum, and cannot be 
> overrode.  So I use an alternative method, nameOf(String).
Okay, that works for me.
>
> Thanks,
> Xuelei
>
>> --Jamil
>>
>>
>> On 4/14/2017 10:48 AM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Adam Petcher have some good comments in a private mail to me. The
>>> webrev is updated accordingly:
>>>
>>>    http://cr.openjdk.java.net/~xuelei/8140436/webrev.01/
>>>
>>> Major update: No customization is allowed for the FFDHE parameters.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>> On 4/13/2017 11:15 AM, Xuelei Fan wrote:
>>>> Hi,
>>>>
>>>> Please review the enhancement to support Finite Field Diffie-Hellman
>>>> Ephemeral (FFDHE) Parameters negotiation in SSL/TLS/DTLS 
>>>> implementation.
>>>>
>>>>    http://cr.openjdk.java.net/~xuelei/8140436/webrev.00/
>>>>
>>>> Updates:
>>>> 1. Support predefined FFDHE parameters.
>>>> JDK will support the following FFDHE parameters defined in RFC 
>>>> 7919, in
>>>> preference order:
>>>>       name        |    key size (bits)
>>>>    ---------------+-------------------
>>>>     ffdhe2048     |    2048
>>>>    ---------------+-------------------
>>>>     ffdhe3072     |    3072
>>>>    ---------------+-------------------
>>>>     ffdhe4096     |    4096
>>>>    ---------------+-------------------
>>>>     ffdhe6144     |    6144
>>>>    ---------------+-------------------
>>>>     ffdhe8192     |    8192
>>>>    ---------------+-------------------
>>>>
>>>>
>>>> 2. Define a new System Property so as to disable the FFDHE mechanism
>>>> For RFC 7919 compatible client, the predefined FFDHE parameter 
>>>> names are
>>>> present in the "supported_groups" TLS extension.  Some server may 
>>>> not be
>>>> able to handle this extension or the FFDHE groups in the 
>>>> extension.   If
>>>> there is an interop issue, the new defined System Property,
>>>> "jsse.enableFFDHE", can be used to dismiss the predefined FFDHE
>>>> parameters for DHE cipher suites.
>>>>
>>>> 3. Redefine the jdk.tls.ephemeralDHKeySize System Property.
>>>> For connection request from RFC 7919 compatible clients, the server
>>>> would prefer to use FFDHE mechanism at first unless
>>>> "jdk.tls.ephemeralDHKeySize" is defined to use "legacy" mode for
>>>> compatibility reason.
>>>>
>>>> jdk.tls.ephemeralDHKeySize | FFDHE                | Server behavior
>>>> ---------------------------+----------------------+---------------------- 
>>>>
>>>>
>>>>   "legacy"                 | in any case          | Use legacy mode.
>>>> ---------------------------+----------------------+---------------------- 
>>>>
>>>>
>>>>   not "legacy"             | Not present in the   | Use DHE parameters
>>>>                            | ClientHello message  | compatible to the
>>>>                            |                      | System Property.
>>>> ---------------------------+----------------------+---------------------- 
>>>>
>>>>
>>>>   not "legacy"             | Present in the       | Use the FFDHE
>>>>                            | ClientHello message  | defined 
>>>> parameters.
>>>>
>>>> Note: Exportable cipher suites do not use the FFDHE mechanism.
>>>>
>>>> 4. Extend the "jdk.tls.namedGroups" System Property
>>>> Extend the "jdk.tls.namedGroups" System Property to support customized
>>>> FFDHE groups.  The following names are now supported by the System
>>>> Property.
>>>>
>>>>     Names for named group  | For EC or DH  | Is it new in the update?
>>>> ------------------------+---------------+-------------------------
>>>>     secp256r1              |  ECDHE        | No
>>>> ------------------------+---------------+-------------------------
>>>>     secp384r1              |  ECDHE        | No
>>>> ------------------------+---------------+-------------------------
>>>>     secp521r1              |  ECDHE        | No
>>>> ------------------------+---------------+-------------------------
>>>>     sect283k1              |  ECDHE        | No
>>>> ------------------------+---------------+-------------------------
>>>>     sect283r1              |  ECDHE        | No
>>>> ------------------------+---------------+-------------------------
>>>>     sect409k1              |  ECDHE        | No
>>>> ------------------------+---------------+-------------------------
>>>>     sect409r1              |  ECDHE        | No
>>>> ------------------------+---------------+-------------------------
>>>>     sect571k1              |  ECDHE        | No
>>>> ------------------------+---------------+-------------------------
>>>>     sect571r1              |  ECDHE        | No
>>>> ------------------------+---------------+-------------------------
>>>>     ffdhe2048              |  FFDHE        | Yes
>>>> ------------------------+---------------+-------------------------
>>>>     ffdhe3072              |  FFDHE        | Yes
>>>> ------------------------+---------------+-------------------------
>>>>     ffdhe4096              |  FFDHE        | Yes
>>>> ------------------------+---------------+-------------------------
>>>>     ffdhe6144              |  FFDHE        | Yes
>>>> ------------------------+---------------+-------------------------
>>>>     ffdhe8192              |  FFDHE        | Yes
>>>> ------------------------+---------------+-------------------------
>>>>
>>>> Thanks,
>>>> Xuelei
>>>>
>>



More information about the security-dev mailing list