The Internet Engineering Task Force (IETF) has released two experimentally marked RFC specifications that outline how TCP traffic can be encrypted. The idea of encrypting TCP is not new. The first draft at the IETF dates back to 2011, and the first was the TCPcrypt project at Usenix 2010. After the project slept for a while, after the revelations of Edward Snowden in 2013 and 2014, it took off again.
One of the reasons for not encrypting TCP, according to RFC 8547, is that a signaling mechanism is missing in many legacy protocols. They can not tell if they support encryption or not. At the same time, many legacy applications can not be updated later. Encryption should therefore be retrofitted and transparently incorporated into the transport layer.
Two RFCs for TCP encryption
The TCP Encryption Negotiation Option (TCP ENO) solves both problems according to the RFC. The new type of TCP option makes it possible to complement a negotiation mechanism for encryption out of the series and fully backwards compatible. This can be done incrementally.
A framework allows two endpoints to negotiate the TCP Encryption Protocol to encrypt the connection between the two endpoints. Multiple TEPs are possible, allowing customization as encryption requirements change in the future. If a page is unable to encrypt, encryption will not occur. Details about TCP-ENO are provided by RFC 8547.
As mentioned, TCPcrypt also includes TCPcrypt, the TCP Encryption Protocol that defines RFC 8548. The authors of the RFC point out that TCPcrypt can peacefully coexist with so-called middleboxes because it tolerates “resegmentation, NATs, and other modifications to the TCP header .”
The protocol is quite self-sufficient, so need no external dependencies such as a PKI, which is important, inter alia, for use in kernel. Key exchange, however, requires an additional hop on hosts that do not yet know each other.
Modern Crypto for TCP Central for TCPcrypt is first an Extract function that receives a salt value and so-called Initial Keying Material (IKM) to generate a pseudo-random key. The extract function will then issue the key. From this, a collision-resistant pseudorandom function (CPRF) then generates several cryptographic keys as well as an arbitrary amount of output keying material (OKM).
These two functions use the Extract and Expand functions of the Key Derivation Function (HKDF) based on HMAC (RFC 2104). Finally, when the keys are negotiated and paired, an Authenticated Encryption with Associated Data (AEAD) algorithm takes care of ensuring the confidentiality and integrity of the submitted application data.
Since the two RFC specifications are explicitly marked as experimental by the IETF , they only show the current state of research and are therefore not intended for productive use. Whether this ever happens is currently not foreseeable. In addition, the IETF uses QUIC on a novel protocol that can serve as a replacement for TCP in the transport layer and is encrypted by default.