Where Does Encryption End? Trace MACsec Frames and TLS Channels

Compare who can access the content

Two offers can both promise encrypted transport while assigning trust to different equipment. One might protect the Ethernet connections into and out of a switch. Another might protect an application channel that crosses the switch. Both descriptions can be accurate, yet answer different access requirements.

Begin with one named application exchange. Ask where its content enters protection, where that protection ends, and what each intermediate component processes. Repeat the question for any protection nested inside the first. This produces a useful comparison of the offers without assuming that a feature label describes the whole path.

MACsec follows frame-protection entities and peers

IEEE 802.1AE concerns protection at the MAC service boundary. A MAC Security Entity, or SecY, performs frame protection and validation. Identify those entities in the proposed equipment and their peer relationships; the application sender and receiver need not be the MACsec endpoints.

IEEE's Security Task Group describes authenticity and integrity with optional confidentiality. Integrity protection addresses undetected alteration; confidentiality addresses disclosure. A statement that MACsec is supported therefore leaves open whether the offered traffic is encrypted. Ask which property the proposal actually includes.

The IEEE overview places MACsec peer discovery and mutual authentication in MKA, the MACsec Key Agreement protocol specified by IEEE 802.1X. That peer relationship concerns the MACsec participants. It does not identify an authenticated application user.

Avoid converting this into a rule that MACsec always ends after one physical cable. IEEE's overview also describes Ethernet Data Encryption devices supporting provider-network arrangements. The protected span follows the actual participating entities and service arrangement. A device between two drawn endpoints might carry protected frames onward or terminate their protection; the drawing needs to say which.

References: [MS1][MS2][MS5]

TLS follows its communicating peers

RFC 8446, the August 2018 TLS 1.3 specification, defines a secure channel between two peers. After establishment, its confidentiality and integrity properties concern data on that channel. The introduction specifies server authentication and optional client authentication.

Locate those peers in the offer: an application process, gateway or proxy can occupy a different boundary from a MACsec-capable port. A switch carrying the exchange is not necessarily a TLS endpoint. The application's destination label alone cannot establish where TLS terminates.

References: [MS3]

Trace the same A—S—B path in two arrangements

Consider Host A—Switch S—Host B. These are deliberately stipulated, unimplemented arrangements for one application exchange. Both use MACsec with confidentiality enabled on A–S and S–B, with separate associations terminating at S. Assume the target frames receive that protection throughout each link. No hardware support, configuration or observed traffic is represented.

In arrangement L, the application has no TLS or other payload encryption. A sends its application content inside MACsec-protected frames. S validates and decrypts the incoming protected data for its own forwarding processing, then applies new MACsec protection for transmission toward B. The content is protected on both links but is available without that encryption inside S's forwarding path. Trusting S with the content is part of this arrangement.

In arrangement T, retain those same MACsec boundaries and stipulate an established TLS channel whose peers are on A and B. S is neither a TLS endpoint nor provided access to the TLS plaintext. When S removes the incoming MACsec layer, the application content remains TLS ciphertext. S forwards that protected payload within the newly protected outgoing frames; B's TLS endpoint recovers the application content.

The distinction is between plaintext relative to a removed layer and plaintext application content. In T, recovery of the MACsec-protected frame data does not recover the application message. In L, the assumptions leave no inner protection.

For a buyer seeking to exclude S from application-content access, L's two encrypted links do not describe that result. T describes a relevant channel boundary. Evidence for a real offer must establish its actual endpoints and behavior before either description can support acceptance.

References: [MS3][MS4][MS5]

Visible metadata and new termination points still matter

Content confidentiality does not imply that every transmitted field is hidden. MACsec's basic frame structure separates addresses and security parameters from the data receiving confidentiality protection. Cisco's conceptual description also expressly identifies unencrypted EAPOL control traffic. The exact exposed fields depend on the offered encapsulation and protection scope.

TLS 1.3 likewise retains a plaintext record header and does not hide transmitted lengths. Ask what headers, control traffic and lengths remain visible at the point being assessed. Application ciphertext and concealed communication metadata are different claims.

If a TLS proxy P terminates A's channel and opens another toward B, P becomes a content-access endpoint. Two protected channels have a different trust boundary from the stipulated A-to-B channel. Similarly, identifying S as a MACsec terminator matters even when both adjacent connections are encrypted. Follow termination rather than counting encryption labels.

References: [MS2][MS3][MS4][MS5][N1]

Ask the supplier to substantiate the boundary it is selling

Request a description that names the application exchange, the MACsec entities and peers, the TLS peers, and the components processing data between them. It should distinguish supported capability, intended enabled protection and evidence about the delivered arrangement. Those statements have different evidential value.

Have the responsible provider identify the exact equipment and software to which its explanation applies, the covered traffic, and any termination or forwarding points left unresolved. Ask who owns the explanation and its acceptance. An equipment feature sheet can establish a capability without establishing the content-access boundary of an installed service.

Neither comparison establishes protection for stored copies or for application processing after a channel ends. Use the related GPU confidential-computing article for execution and attestation boundaries. Its separate decision should remain visible when a supplier combines network encryption and protected-compute claims. This article supports comparison of offers; the appointed network, application and security owners assess the actual design and acceptance.

Carry the selected connections into the physical package

Where the selected equipment requires cabling work, use Leviathan's Structured Cabling & Fiber Installation service and the project inquiry linked below to discuss approved endpoints, routes, dressing, labels and connection records. Identify the materials supplier, site constraints and receiving team in a nonconfidential project outline.

The physical records can identify which ports were connected. MACsec or TLS configuration, cryptographic operation and security acceptance remain with separately appointed technical owners. Agree the physical tasks and returned records so that the network team can relate the installation to its own endpoint assessment.

References: [L1]