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.
