Encrypted Stream Transmission Protocol

Stream Control Transmission Protocol (SCTP) is replacement or upgrade of the original Transmission Control Protocol (TCP), with significant improvements. One enhancement SCTP failed to include was encryption. This is left to protocols built on top of TCP or SCTP such as TLS (and also hybrid protocols such as STARTTLS) to be negotiated after the SCTP connection is established. However, this adds additional delay and it exposes the early portions of the connection to eavesdropping and possible hijacking. It is becoming increasingly clear that all Internet traffic should be encrypted and authenticated, and in my opinion that should be made as efficient as possible. I therefore propose a new protocol to replace SCTP, which I shall named Encrypted Stream Transmission Protocol (ESTP). ESTP makes use of enhancements to the Domain Name System (DNS) protocol (EDNS) that include encryption and host public keys. This proposal also facilitates the HTTP Virtual Host mechanism.

Glossary

Overview

Background — DNS / SCTP / TLS today

For simplicity this example will use two-level virtual host names. The extension to arbitrary virtual host names is obvious. We also show the case where the client does its own address resolution rather than one where an independent resolver is used.

Note: the following is based on HTTPS-like protocols; protocols where STARTTLS is used (e.g. SMTP, IMAP) are even lengthier.

Please note that a great deal of metadata is sent in cleartext, such as the hostnames, cipher negotiation, server certificates, and client certificate.

The DNSSEC portion of the above is easily exploitable for a Distributed Reflection Denial of Service (DrDoS) attack. DNS Response Rate Limiting (DNS RRL) is more of a bandaid than a solution.

Proposed EDNS / ESTP

These protocols are built upon authenticated encryption (AE) with added digital signatures. Most likely AE would be Galois Counter Mode (GCM) with AES as the block cipher. However, it is desirable to generalize this to non-block ciphers to allow eSTREAM ciphers and their follow ons (such as ChaCha). Since GCM is simply a stream cipher created from the block cipher operated in counter mode concatenated with a Galois Message Authentication Code (GMAC) of the ciphertext, it is easy to generalize to an arbitrary stream cipher by specifying how to derive the hash key value. For GCM this is the block cipher applied to the zero block. For a stream cipher the first stream value could be used instead. (I am unsure why NIST did not use the first GCTR_K value as the key for the Galois hash, since this seems equally good as the block cipher of zero. If someone knows a reason, please let me know.) Alternatively the hash key could be derived by the KDF used to generate the symmetric key and IV. Just as in GCM, a stream value is XORd with the keyed hash to generate a cryptographic hash, and just as in GCM, the associated data lengths and ciphertext data lengths are included in the keyed hash when a stream cipher is used. GCM, as used subsequently, shall include this generalization.

When a client first contacts a server (either EDNS or ESTP), it is desirable that the connection details be hidden to minimize metadata eavesdropping. Forward Secrecy is not possible at this point, but asymmetric cryptography is. This is accomplished by encrypting the data with a symmetric stream cipher (e.g. AES-CTR or eSTREAM) using a randomly generated key, IV, and perhaps MAC key, and encrypting these values with the server’s public key. Since these values may require padding before public-key encryption, the client would actually generate a random string of the appropriate length for public-key encryption, and both client and server would apply a Key Derivation Function (KDF), such as NIST Special Publication 800-56A Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography 5.8.1 or NIST Special Publication 800-56B Recommendation for Pair-Wise Key Establishment Schemes Using Integer Factorization Cryptography 5.9.1, to this random data to create the key, IV, and optional MAC key. The ciphertext would be authenticated with a MAC (e.g. GMAC) as above.

In the first exchange with another host, MAC values (e.g. 128-bit GMAC) are further encrypted with a private key (that is signed) so as to prove identity and defeat MITM attacks. They are verified by decrypting them using the public key before verifying the MAC. MAC values may require padding before encryption with long public keys (e.g. RSA). In this case, it may be preferable to simply use a MAC value of the appropriate length? Alternatively ciphertext values could be included to provide padding. This is another reason to prefer elliptic curve cryptography.

However, it may not be necessary for the server to sign its response to the client, since only the server would be capable of decrypting the query encrypted with its public key and replying with the same symmetric authenticated encryption parameters. This needs further consideration.

EDNS servers shall have at least one NSPubkey / NSSecKey pair for signing (e.g. encrypting the ciphertext MACs) and encrypting symmetric encryption keys. They may have multiple keys and associated algorithms, specified in multiple PKEY records, allowing the client to choose which algorithm to use. Servers could use either RSA or elliptic curve cryptography. However, RSA requires 3072-bit keys to secure 128-bit symmetric keys and 15360-bit keys to secure 256-bit symmetric keys, compared to just 256 bits and 521 bits for elliptic curves (see NIST Special Publication 800-57 Recommendations for Key Management — Part 1: General (Revision 3), Table 2. Long keys are not only costly to transmit (e.g. from EDNS servers), but also require long messages for encryption, so either OAEP+ padding is required, or a long random string for input to a KDF. It is therefore unclear why RSA keys would continue to be used in a new protocols such as EDNS and ESTP, where backward compatibility is not required. I expect initial implementations to use 521-bit ECC, where clients send 65 bytes of random data, and client and server both use a KDF to generate a 128-bit AES or ChaCha key and a 128-bit hash key (e.g. for GMAC).

VHost Bob has a BobPubKey and BobSecKey pair for signing (e.g. encrypting ciphertext MACs). VHost Bob may physically share a PHost with other VHosts. This protocol shall allow that PHost to determine which VHost the client is requesting. This solves the problem with HTTPS where a single key must be shared by all VHosts on a single PHost. It does this by getting BobPubKey from Bob’s domain name server in parallel BobAddr, and encrypting the ciphertext MAC with this key. Trial decryptions allow PHost Bob to know which public key was used, and thus which VHost is being accessed. This is done rather than sending something in the clear to minimize what metadata is available to an eavesdropper.

VHost Alice has one or more AlicePubkey and AliceSecKey pairs for encrypting symmetric encryption keys and signing (e.g. encrypting GCM MACs). AlicePubkey may be used as a userid by some servers. It is recommended that a different public key be used for each server to prevent the userid being used for tracking. These keys need not be signed by a certificate authority (just as usernames are not signed), so Alice may create as many as she needs. Servers may also accept multiple public keys as identifying Alice, so that she needn’t synchronize keys between all of her systems.

The EDNS portion of the above is easily exploitable for a Distributed Reflection Denial of Service (DrDoS) attack, just as with DNSSEC. DNS Response Rate Limiting (DNS RRL) is more of a bandaid than a solution. It may be appropriate to swallow another RTT to give a better solution, but that is a digression from the the main point of this investigation.

Anticipated FAQ

Why encrypt the Diffie-Hellman parameters?

Diffie-Hellman (DH) key exchange was invented to allow key exchange even with eavesdropping, so encrypting the key exchange is not necessary for key privacy as long as DH remains secure. However, the act of key exchange might reveal something to an eavesdropper, even if she cannot learn the negotiated key. For example, it might be possible to fingerprint clients based on their DH parameter selection. Encrypting the exchange eliminates such potential metadata analysis. Also, should an attack be developed against DH at some future date, encrypting the exchange maintains security until public-key cryptography is similarly broken.

Why reverse the roles compared to TLS between client and server for Diffie-Hellman parameters?

This change was made to reduce latency while maintaining the DoS-resistance that comes from not building a TCB on the server until receiving the second packet from the client (the COOKIE_ECHO). They could be sent in the INIT_ACK and stored in BobCookie to be echoed back in COOKIE_ECHO, but this seems excessive, unless there turns out to be a reason to keep the TLS roles.

Could this be built upon UDP?

Yes. I think this would be necessary in the beginning.

How does this compare to Google QUIC?

I don’t know. I only just learned about QUIC by showing this page to acquaintances.

What is wrong with this protocol?

Having to try decryption with the INIT GCM with each VHost secret key is inelegant and computationally expensive. But it is better than the HTTPS situation where all VHosts must share a single certificate.

How does ESTP compare to DTLS?

DTLS uses three round-trip times (RTTs) to initiate a connection, and so is slower than ESTP. It is also a datagram protocol rather than a reliable stream protocol.

Could IPSEC be used instead?

Another alternative would be to have all IP traffic between hosts be end-to-end encrypted (e.g. by IPSEC). This would eliminate the need to have a separate EDNS protocol, for example, since DNSSEC UDP packets transmitted by IPSEC would be encrypted. Currently IPSEC setup is much longer than ESTP (Phase 1 is three RTT, and Phase 2 is three RTT), so perhaps the question should be whether ESTP’s purposes could be served by an IP-level protocol (i.e. new improved IPSECv2). That is worthy of consideration.

IPSECv2?

What would a low-latency IP-level encryption protocol look like? Let’s call this IPSECv2 here. First, it would depend on the agent that hands out IP addresses (e.g. DNS) providing public keys, as in EDNS / ESTP above for latency reduction. Software that originates packets provides both the IP address and public key to the relevant API.

When a PHost attempts to originate any packet, it would check the destination host address in a hash table to retrieve the encryption parameters to use, encrypt the payload with an AEAD algorithm (e.g. encrypt-then-MAC algorithms AES-GCM or ChaCha-GCM), including the header in the authentication (NAT-T to be addressed later). It would package this up in an IP packet with type IPSECv2 (e.g. 138) and transmit.

The interesting case is when the hash table fails to find encryption parameters for a destination IP address. (This case might be handled by a daemon rather than in the kernel, but that isn’t relevant here.) In this case it initiates a PHost-to-PHost UDP packet exchange with the equivalent of INIT, INIT_ACK, COOKIE_ECHO, and COOKIE_ACK, with each side in this exchange entering the resulting encryption parameters into the hash table to enable the original packet to finally be transmitted.

Some mechanism for purging entries from the hash table is necessary, especially on a busy server. Receipt of a packet from a PHost not in the hash table would be answered with the equivalent of INIT_ACK to re-setup the encryption parameters (the received packet would be discarded and have to be retransmitted using the new encryption parameters). The INIT_ACK should be shorter than the original packet, to avoid amplification DoS attacks. If this is not the case, a short NEED_INIT might be used, requiring an extra RTT.

This has rather longer setup time when used to protect DNSSEC traffic than EDNS proposed above, and so a specialized encrypted DNS protocol like EDNS may still be necessary for latency reduction. However, Reflection Denial of Service attacks are such a basic problem for the Internet, that perhaps a comprehensive solution is required. I therefore suggest that the clients be required to request a cookie from a server before their first packet (either datagram or connection setup), and to include that cookie in their first packet to prove they receive packets at their source IP address. Cookies would have time-to-live (TTL) values provided by the server (probably measured in hours), and after a cookie expires, clients would have to request a new one. Cookies must not require server resources, but must be verifiable by the server as something it originated in response to the same IP address is now using the cookie (multihoming needs to be addressed). This adds latency to EDNS, but if the TTL values are measured in hours, it may be incurred only infrequently and therefore be acceptable. The server response to a packet with an expired or invalid cookie is simply to drop the packet. The response to multiple cookie requests from the same IP address should be limited, since that situation indicates either spoofing or network connectivity issues, neither of which can be fixed with repeated responses.

To handle NAT-T I propose that the INIT UDP packet include the original IP source address in the body, so that if the source address in the header is modified, this is detected on the server on receipt of the INIT and on the client on receipt of the INIT_ACK. In this case, UDP-encapsulation is used for all data packets, not just the subsequent COOKE_ECHO and COOKIE_ACK. This gives the NAT device a source port to modify and associate with the connection. A KeepAlive mechanism should be used at a higher level protocol to keep NAT associations in place.

As an aside, it is amusing to note that these protocols have a distant resemblence to the old ARPAnet Host-to-Host protocols, where congestion control was done between hosts rather than between processes.