PQConnect: Compatibility

PQConnect
Intro
For users
For sysadmins
Compatibility
Security
Cryptography
Changes
Papers
PQConnect: Compatibility

## Backward compatibility

Preserving connectivity is critical. After you install the PQConnect client software, your machine will connect to PQConnect servers and will continue to connect to non-PQConnect servers. PQConnect is designed so that the PQConnect client software detects PQConnect servers without sending extra queries to non-PQConnect servers. (Such queries might trigger hyperactive firewalls to break connectivity.) Similarly, if you are a sysadmin installing the PQConnect server software, your machine will continue to allow connections from non-PQConnect clients.

This compatibility works using CNAME records, a standard DNS feature (for example, `www.amazon.com` relies on CNAME records). To announce PQConnect support for `www.your.server`, you will rename the existing DNS records for `www.your.server` (typically just an A record showing the server's IP address) under a new name determined by PQConnect, and you will set up a DNS CNAME record pointing from `www.your.server` to the new name. For example, `www.pqconnect.net` has a CNAME record pointing to `pq1u1hy1ujsuk258krx3ku6wd9rp96kfxm64mgct3s3j26udp57dbu1.pqconnect.net`, which in turn has an A record listing the server's IP address. Non-PQConnect clients follow the CNAME record and connect to the server. PQConnect clients recognize the CNAME record as a PQConnect announcement and make an encrypted connection to the server.

## Forward compatibility

PQConnect announcements include a version number `pq1`. This supports smooth future upgrades in which clients are upgraded to allow a modified `pq2` protocol, and then servers can freely begin announcing `pq2`.

## Subdomains

PQConnect is not limited to `www.your.server`. You can also announce PQConnect support for `imap.your.server`, `zulip.your.server`, or whatever other subdomains you want within your DNS domains.

However, you cannot set up a DNS CNAME record specifically for the second-level name `your.server` delegated from the top-level `.server` administrators. DNS does not allow CNAME records to have exactly the same name as other records, such as delegation records. It would be possible for PQConnect to work around this restriction by inserting PQConnect announcements into delegation records, but currently PQConnect focuses on protecting subdomains.

## Operating systems

The initial PQConnect software release is for Linux. The software installation relies on packages supplied by Linux distributions. Package names are not synchronized across Linux distributions. The installation currently understands the names for Debian; Debian derivatives such as Ubuntu and Raspbian; Arch; and Gentoo. Adding further distributions should be easy.

Support for non-Linux operating systems is planned, handling the different mechanisms that different operating systems provide for reading and writing IP-layer packets. The PQConnect system as a whole is designed to be compatible with any operating system. The PQConnect software is written in Python. The underlying C libraries for cryptography have already been ported to MacOS.

Accessing the IP layer is not the only way to implement the PQConnect protocol. Existing user-level applications access the kernel's network stack via system calls, normally via `libc`. It is possible to modify those network packets by modifying the kernel, by modifying `libc`, or by pre-loading a PQConnect dynamic library, still without touching the individual applications. Also, most applications access DNS at the servers designated in `/etc/resolv.conf`, usually via `libc`, so it is possible to modify DNS packets by changing `libc`, by modifying `/etc/resolv.conf` to point to local DNS software that handles PQConnect, or by modifying existing local DNS software to handle PQConnect (via plugins where applicable, or by code modifications). These software choices can also be of interest to apply PQConnect to applications that manage to dodge the current PQConnect software.

## Applications

Our experiments have found the PQConnect software successfully wrapping post-quantum cryptography around a wide range of applications. However, there is no guarantee that PQConnect covers all applications. For example, an application might read a server address from a local file without using DNS queries, might use its own encrypted tunnel to a DNS proxy, or might otherwise deviate from the normal modular usage of DNS services provided by the operating system. These applications do not receive the benefits of PQConnect: they will continue to make non-PQConnect-protected connections as usual.

A notable example is Firefox, which automatically uses DNS over HTTPS in some cases to send DNS queries to Cloudflare. A DNS proxy (or DNS packet rewriting) can disable this by creating an IP address for `use-application-dns.net`; this allows Firefox to benefit from PQConnect, and is still compatible with passing DNS queries locally to a modular DNS-over-HTTPS client. A user manually configuring Firefox to use DNS over HTTPS will prevent Firefox from using PQConnect.

## Transport-layer security

SSH connections, TLS connections, etc. work smoothly over PQConnect. The software managing those security mechanisms doesn't notice that everything is protected inside a PQConnect tunnel. The PQConnect software doesn't notice that the packets it's encrypting already have another layer of encryption.

## VPNs

Conceptually, running the PQConnect protocol on top of a VPN protocol, or vice versa, is a simple matter of routing packets in the desired order through PQConnect and the VPN. So far we haven't written scripts to do this, but if you have specific use cases then please share details in the Compatibility channel on the PQConnect chat server.

## Firewalls

PQConnect encrypts and authenticates complete IP packets, including port numbers. After decrypting a packet, PQConnect forwards the packet to the local machine on whichever port number is specified by the client. One consequence of this encryption is that you cannot rely on a firewall outside your machine to block ports: any desired port blocking must be handled by a firewall inside your machine. Note that an external firewall also does not block attackers who have compromised a router or network card between the firewall and your computer.

You may be behind a firewall that restricts which ports you can use: for example, the firewall may block low ports, or may block high ports. PQConnect is flexible in which ports it uses. The `-p` option for the `pqconnect` program chooses a client port. The `-p` and `-k` options for the `pqconnect-server` program choose a crypto-server port and a key-server port. All of these are UDP ports.

## IP versions

Our PQConnect tests have been with IPv4, but the protocol should also work with IPv6. The PQConnect handshake packets are small enough that even multiple levels of surrounding tunnels should stay below the 1500-byte Ethernet limit on packet sizes.

## Application-layer surveillance

The PQConnect server software automatically replaces client IP addresses with local addresses such as 10.10.0.5 when it delivers packets to applications running on your server. Hiding client addresses can help protect privacy against applications that are careless in handling client data, and can help comply with privacy regulations.

If you need applications to be able to check client locations to route clients to nearby servers for efficiency, one option is to provide different DNS responses to clients in different locations (using, e.g., the "client location" feature in tinydns), already pointing those clients to nearby servers at DNS time rather than having the application perform this routing. If you need to check client information in logs for abuse tracking, one option is to collate PQConnect logs and application logs, still without exposing client IP addresses to the application.

Version: This is version 2024.12.26 of the "Compatibility" web page.