CAS-004 Security Engineering Practice Question
A security engineer is reviewing a TLS 1.3 configuration. Which of the following is a key feature of TLS 1.3 that improves security compared to earlier versions?
⚠ Common exam trap
CAS-005 often tests the misconception that TLS 1.3 supports legacy ciphers like RC4 or static RSA, when in fact it removed them and mandates forward secrecy.
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 using ephemeral Diffie-Hellman
TLS 1.3 mandates forward secrecy by requiring ephemeral Diffie-Hellman key exchange (DHE or ECDHE), which ensures that session keys cannot be recovered even if the server's long-term private key is later compromised. This is a core security improvement over TLS 1.2, where static RSA key exchange was allowed and lacked forward secrecy.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Mandatory forward secrecy using ephemeral Diffie-Hellman
Why this is correct
TLS 1.3 mandates ephemeral Diffie-Hellman key exchange for all cipher suites, so every session derives unique keys and compromise of the long-term key cannot decrypt past traffic. Earlier versions permitted static RSA key transport, which lacked this property.
- ✗
Support for RC4 cipher suite
Why it's wrong here
RC4 is prohibited in TLS 1.3; the protocol permits only AEAD ciphers such as AES-GCM and ChaCha20-Poly1305. It is tempting because RC4 appeared in TLS 1.0–1.2 cipher suites and older documentation, and would only be a consideration when assessing deprecated legacy protocol configurations.
- ✗
Support for static RSA key exchange
Why it's wrong here
TLS 1.3 removed static RSA key exchange entirely, so no configuration can enable it; forward secrecy is mandatory via ephemeral (EC)DHE. It is tempting because static RSA was common in TLS 1.2 and appears in older cipher suites, and would be relevant only when reviewing legacy TLS 1.2 configurations.
- ✗
Ability to downgrade to TLS 1.2
Why it's wrong here
TLS 1.3 removed renegotiation and legacy downgrade paths, so permitting fallback to 1.2 reintroduces the weaknesses the version was designed to eliminate. It is tempting because backward compatibility eases mixed-client deployments, and would be correct if the question asked about interoperability rather than security improvement.
Quick reference
Asymmetric Encryption Algorithm Comparison
| Algorithm | Key Exchange | Signatures | Equivalent Security Key | Notes |
|---|---|---|---|---|
| RSA-3072 | Yes | Yes | 128-bit | Widely deployed; slow for bulk data |
| ECDSA P-256 | No | Yes | 128-bit | Fast signatures; standard TLS certs |
| ECDH / ECDHE | Yes | No | 128-bit | Perfect forward secrecy in TLS 1.3 |
| DH / DHE | Yes | No | 128-bit (3072-bit key) | Replaced by ECDHE in modern TLS |
| Ed25519 | No | Yes | ~128-bit | SSH keys, modern PKI |
About these practice questions
This CAS-005 question is part of Courseiva's 973-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official CompTIA exam blueprint
This CAS-005 practice question is part of Courseiva's free CompTIA certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CAS-005 exam.