1

Using the cipher suite “TLS_AES_128_CCM_SHA256”

This example is referring to a self signed certificate

If a server uses TLS and uses the cipher suite above? How does the certificate get signed if there is not an asymmetric private key to sign it with?

Is the AES premaster secret sent clear text since there is not a public key to encrypt it with?

What is the most secure way to use this type of certificate and cipher suite if you have to?

1
  • 2
    I'm not sure if I understand the question. First, the cipher is mostly irrelevant here, i.e. any cipher which supports certificate based authentication fits the purpose. This is a TLS 1.3 cipher so it does not even define the authentication method. Then, with self-signed certificates the certificate is signed by itself, i.e. using the private key matching the public key of the certificate. So there is an asymmetric algorithm involved, only it is not specified in the cipher. Which means the base assumption of this question is wrong. Dec 15 '21 at 4:31
2

From my understanding, you are asking why there is no mention of an asymmetric algorithm in the cipher suite “TLS_AES_128_CCM_SHA256”, and the certificate is not relevant to the question.

This is because TLS1.3 negotiates it differently than it used to be, as detailed in RFC8446 Section 4.1.1 - Cryptographic Negotiation:

In TLS, the cryptographic negotiation proceeds by the client offering the following four sets of options in its ClientHello:

  • A list of cipher suites which indicates the AEAD algorithm/HKDF hash pairs which the client supports.

  • A "supported_groups" (Section 4.2.7) extension which indicates the (EC)DHE groups which the client supports and a "key_share" (Section 4.2.8) extension which contains (EC)DHE shares for some or all of these groups.

  • A "signature_algorithms" (Section 4.2.3) extension which indicates the signature algorithms which the client can accept. A "signature_algorithms_cert" extension (Section 4.2.3) may also be added to indicate certificate-specific signature algorithms.

  • A "pre_shared_key" (Section 4.2.11) extension which contains a list of symmetric key identities known to the client and a "psk_key_exchange_modes" (Section 4.2.9) extension which indicates the key exchange modes that may be used with PSKs.

Note that RFC8442 regarding TLS1.2 also quotes your cipher suite explaining it is used to "support equivalent functionality in TLS 1.3".

Not the answer you're looking for? Browse other questions tagged or ask your own question.