What is the Impact of Encrypting Transport-layer Protocol Headers?

As part of the trend towards increasing use of end-to-end encryption on the Internet, we've started to see moves to encrypt the transport layer headers in addition to the payload data. The QUIC transport protocol is one example of a transport with this behaviour. Encrypting these headers has some widely discussed benefits: it reduces information leakage and provides some small privacy benefit, it helps prevent certain spoofing and injection attacks against the transport, and it limits the scope for middlebox-related ossification of the stack. The costs incurred by encrypting these headers have been less widely discussed, however. Gorry Fairhurst and I wrote a draft that considers these costs, that we presented in the OPSEC and TSVWG working groups at IETF 100 in Singapore in November 2017.

Gorry Fairhurst presenting in the OPSEC working group at IETF 100

The use of transport-layer header encryption has two costs: it complicates both network operations and protocol specification. Considering network operations, we note that leaving transport headers unencrypted, i.e., observable, allows network operators to easily analyse overall network performance, and can help to detect anomalies, inform capacity planning, and inform traffic engineering. That is, it allows operators to gain a passive view of the overall health of their network and helps them to detect problems before they impact customer experience. Operators we've spoken to note that this feature is important for managing their networks, and if the transport headers are encrypted, preventing access to this information, they'll have to develop alternatives such as active traffic probes or encapsulations to replace the missing headers. Similarly, some forms of traffic engineering rely on monitoring the overall flows of traffic through the network, informed by transport protocol performance derived from header measurements.

Encrypting transport headers limits the open and verifiable data on transport behaviour that's available to network operators and the research community. This makes it difficult to tell if transports are behaving as intended, and means the community loses the data to inform future developments and to understand operational behaviour of transport protocols. Endpoint telemetry helps here, but is less accessible and is not necessarily trustworthy.

Similarly, understanding transport misbehaviour relies on being able to observer transport headers. This is essential for transport protocol research and protocol debugging by operators/vendors, and needs to happen in the wild -- test-beds can verify feature interactions problems, but can't be used to discover them.

Finally, we note that role of transport-layer measurements in supporting common protocol specification, compliance with operational practice, and research and development. TCP works so well because it's an open protocol and can be observed and improved by all. Pervasive encryption of transport headers removes a set of checks-and-balances, and reduces the incentives to conform to specifications. It leads to faster innovation, which is desirable, but also runs the risk of closed point solutions that are fragile, only work in specific scenarios, and that are difficult to debug since the data to do so isn't available to the wider community. This is potentially a problem for the long-term health of the standard ecosystems and the network.

As RFC 7258 notes "While PM [pervasive monitoring] is an attack, other forms of monitoring that might fit the definition of PM can be beneficial and not part of any attack, e.g., network management functions monitor packets or flows and anti-spam mechanisms need to see mail message content. Some monitoring can even be part of the mitigation for PM, for example, certificate transparency involves monitoring Public Key Infrastructure in ways that could detect some PM attack techniques. However, there is clear potential for monitoring mechanisms to be abused for PM, so this tension needs careful consideration in protocol design. Making networks unmanageable to mitigate PM is not an acceptable outcome, but ignoring PM would go against the consensus documented here. An appropriate balance will emerge over time as real instances of this tension are considered" (emphasis added).

We are not against transport-level header encryption. It offers important benefits, but also has costs for operations, protocol development, and standards. We must seek balance: obstructing real operations needs will lead to workarounds being deployed, and will likely not increase privacy.