Network and Communications Security →hardMultiple Select

SSCP Network and Communications Security Practice Question

A security analyst is reviewing a TLS 1.3 deployment. Which THREE of the following are features of TLS 1.3?

⚠ Common exam trap

SSCP often tests the misconception that TLS 1.3 is backward compatible with SSL 3.0 or that static RSA remains an option — candidates who confuse TLS 1.2 features with TLS 1.3 pick A or E.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Mandatory forward secrecy

Option B is correct because TLS 1.3 mandates forward secrecy by eliminating static RSA and static Diffie-Hellman key exchange, requiring ephemeral key exchanges (ECDHE or DHE) so that compromise of long-term keys cannot decrypt past sessions. Option C is correct because TLS 1.3 introduces a 0-RTT (early data) mode using PSK resumption, allowing the client to send application data in the first flight, though it carries replay risk. Option D is correct because TLS 1.3 removes all legacy cipher suites based on RC4, DES/3DES, CBC-mode, and MD5/SHA-1, restricting the protocol to AEAD ciphers such as AES-GCM, ChaCha20-Poly1305, and AES-CCM. Option A is not correct because static RSA key exchange was explicitly removed in TLS 1.3, since it lacks forward secrecy. Option E is not correct because TLS 1.3 does not support SSL 3.0 compatibility; SSL 3.0 was already deprecated and TLS 1.3 removed backward compatibility with such legacy protocols.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Use of static RSA key exchange
Why it's wrong here
TLS 1.3 abolished static RSA key exchange, replacing it with ephemeral Diffie-Hellman modes such as ECDHE, which provide forward secrecy. Static RSA remains available in TLS 1.2 and is chosen when forward secrecy is not required.
✓
Mandatory forward secrecy
Why this is correct
TLS 1.3 removes static RSA and plain Diffie-Hellman key exchange, leaving only ephemeral (EC)DHE and PSK modes. Every session therefore derives unique keys, so forward secrecy is mandatory rather than optional as in TLS 1.2.
✓
Support for 0-RTT handshake
Why this is correct
TLS 1.3 permits a 0-RTT mode where the client sends application data with its first flight using a previously established pre-shared key, removing a full round trip. This reduces latency for resumed connections, a defining feature absent from TLS 1.2.
✓
Removal of cipher suites like RC4 and DES
Why this is correct
TLS 1.3 removes all legacy cipher suites, including RC4 and DES, retaining only authenticated encryption with associated data (AEAD) algorithms such as AES-GCM and ChaCha20-Poly1305. This eliminates weak, deprecated primitives, directly satisfying the stem's requirement to identify genuine TLS 1.3 features rather than TLS 1.2 capabilities.
✗
Support for SSL 3.0 compatibility
Why it's wrong here
TLS 1.3 removed SSL 3.0 compatibility entirely, along with all legacy protocol fallback; the handshake has no downgrade path to SSL. SSL 3.0 support belongs to older TLS 1.2 deployments configured for backward compatibility with legacy clients.

Quick reference

Symmetric Encryption Algorithm Comparison

Algorithm	Key Size	Block Size	Status	Notes
AES-128	128-bit	128-bit	Current standard	NIST approved; WPA3, TLS
AES-256	256-bit	128-bit	Current standard	Preferred for sensitive / govt data
3DES	112-bit effective	64-bit	Deprecated (2023)	Replaced by AES
DES	56-bit	64-bit	Broken	Cracked in < 24 h; never deploy
ChaCha20	256-bit	Stream cipher	Current	TLS 1.3, WireGuard

Go deeper

SSCP Network and Communications Security Practice Question

Why each option matters

Option-by-option breakdown

Symmetric Encryption Algorithm Comparison

Related to this question