Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8224520

Support X25519 and X448 in TLS

XMLWordPrintable

    • Icon: CSR CSR
    • Resolution: Approved
    • Icon: P2 P2
    • 13
    • security-libs
    • None
    • behavioral
    • low
    • Hide
      In TLSv1.3, if our implementation contacts a server that doesn't support these new curves, the server is supposed to respond with a request to use a different curve. If the server doesn't follow the RFC properly, there could be interoperability problems. Switching curves is core handshake functionality, so I don't expect there to be interop problems like this.

      This particular problem doesn't exist with earlier TLS versions, as the client specifies the possible curves, and the server picks one to use.
      Show
      In TLSv1.3, if our implementation contacts a server that doesn't support these new curves, the server is supposed to respond with a request to use a different curve. If the server doesn't follow the RFC properly, there could be interoperability problems. Switching curves is core handshake functionality, so I don't expect there to be interop problems like this. This particular problem doesn't exist with earlier TLS versions, as the client specifies the possible curves, and the server picks one to use.
    • System or security property, File or wire format
    • JDK

      Summary

      Adds support for x25519/x448 Elliptic Curves (RFC 7748) to the JDK TLS implementation.

      Problem

      JEP 324 added KeyAgreement with ECC curves x25519/x448 to JDK 11. These curves have desirable properties:

      ...constant-time implementation and an
      exception-free scalar multiplication that is resistant to a wide
      range of side-channel attacks, including timing and cache attacks.

      These curves were recently added to the various IETF Transport Layer Security (TLS) specifications:

      Currently, the JDK SunJSSE provider does not support these curves.

      Solution

      Add support for x25519/x448 in the SunJSSE implementation.

      Almost all of the implementation changes are contained within the JDK internal SunJSSE provider code.

      x25519 is the most preferred named group in Chrome, Firefox, Opera, and Edge, so we will follow suit.

      Specification

      x25519/x448 will be added to the list of "enabled by default" named curves.

      The only externally noticeable item is that the strings "x25519" and "x448" are now recognized in the java.lang.System configuration property "jdk.tls.namedGroups":

      jdk.tls.namedGroups="x25519, x448, secp521r1, secp256r1, ffdhe2048"

      Proposed default ordered list of groups:

        // Primary XDH (RFC 7748) curves
        NamedGroup.X25519,
      
        // Primary NIST curves (i.e. used in TLSv1.3)
        NamedGroup.SECP256_R1,
        NamedGroup.SECP384_R1,
        NamedGroup.SECP521_R1,
      
        // Secondary XDH curves
        NamedGroup.X448,
      
        // Secondary NIST curves
        NamedGroup.SECT283_K1,
        NamedGroup.SECT283_R1,
        NamedGroup.SECT409_K1,
        NamedGroup.SECT409_R1,
        NamedGroup.SECT571_K1,
        NamedGroup.SECT571_R1,
      
        // non-NIST curves
        NamedGroup.SECP256_K1,
      
        // FFDHE 2048
        NamedGroup.FFDHE_2048,
        NamedGroup.FFDHE_3072,
        NamedGroup.FFDHE_4096,
        NamedGroup.FFDHE_6144,
        NamedGroup.FFDHE_8192,

            wetmore Bradford Wetmore
            xuelei Xuelei Fan
            Xuelei Fan
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: