OpenSSL 1.1.1 KAS for TLS 1.2.

[Viktor Dukhovni]

On Fri, Jul 28, 2023 at 09:32:48PM +0000, Malkin, Vlad wrote:

> We're trying to determine what KAS is provided by OpenSSL 1.1.1 when
> using TLS 1.2 with TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.

The one specified for use with TLS 1.2:

  https://datatracker.ietf.org/doc/html/rfc8422#section-2.1
  https://datatracker.ietf.org/doc/html/rfc8422#section-5.10
  http://ieeexplore.ieee.org/document/891000/

    All ECDH calculations for the NIST curves (including parameter and
    key generation as well as the shared secret calculation) are
    performed according to [IEEE.P1363] using the ECKAS-DH1 scheme with
    the identity map as the Key Derivation Function (KDF) so that the
    premaster secret is the x-coordinate of the ECDH shared secret
    elliptic curve point represented as an octet string.  Note that this
    octet string (Z in IEEE 1363 terminology), as output by FE2OSP (Field
    Element to Octet String Conversion Primitive), has constant length
    for any given field; leading zeros found in this octet string MUST
    NOT be truncated.

    (Note that this use of the identity KDF is a technicality.  The
    complete picture is that ECDH is employed with a non-trivial KDF
    because TLS does not directly use the premaster secret for anything
    other than for computing the master secret.  In TLS 1.0 and 1.1, this
    means that the MD5- and SHA-1-based TLS Pseudorandom Function (PRF)
    serves as a KDF; in TLS 1.2, the KDF is determined by ciphersuite,
    and it is conceivable that future TLS versions or new TLS extensions
    introduced in the future may vary this computation.)

> Is the KAS configurable and how?

For interoperability of applications using the TLS protocol, the KAS is
fixed by TLS specification, and is not "configurable".

-- 
    Viktor.