Exercise 2: Why TLS Couldn't Happen Before the TCP Handshake Completed — Possible Solution
====================================================================

Explanation:

Per this chapter's own attribution table, Step 4 (TLS layered on top
of TCP) traces back to net1-2, net1-3, and net1-7 -- and it's net1-7
specifically that carries the load-bearing reasoning here. Per this
chapter's own Step 4 description, TLS's handshake is "a genuinely
separate TLS handshake... building an encrypted channel on top of the
already-reliable connection underneath" -- the phrase "already-reliable
connection" is doing the real work: TLS's own handshake consists of
actual data being exchanged (certificates, key negotiation messages),
and that data needs a working, reliable transport to travel over.

Tracing back to net1-7's own reasoning (covered in that chapter's own
Exercise 1, which this scenario directly parallels): TCP's reliability
guarantees -- correct delivery, correct ordering, no duplication -- all
depend on the sequence-number-based mechanism that only becomes active
once the three-way handshake (Step 3: SYN, SYN-ACK, ACK) has fully
completed. Before that handshake finishes, there is no established
connection with working sequence numbers, no acknowledgment mechanism,
and no reliable channel at all -- just a one-way or partially-
acknowledged exchange in progress. TLS handshake messages sent before
Step 3 completed would have no reliable connection to actually travel
over.

This is also why this chapter's own Step 4 explicitly calls this "two
handshakes, strictly sequential, not one" -- rather than TLS and TCP
negotiating simultaneously or TLS starting first, the TCP handshake
(Step 3) must fully finish, establishing the reliable connection, before
the TLS handshake (Step 4) can even begin sending its own first
message.

WHY THIS WORKS AS AN ANSWER
------------------------------
This traces back through the chapter's own attribution table to
net1-7's specific reasoning about TCP's reliability mechanism
depending on a completed handshake, rather than simply restating that
the steps happen "in order" without explaining the underlying
dependency.