[Masque] Encrypting between client and proxy

[Martin Thomson <[e-mail]>]

In draft-pauly-masque-quic-proxy, though connection IDs are replaced as packets hit the proxy, the content of those packets otherwise is unchanged.  This makes it trivial to correlate packets as they flow past a proxy[1].

In discussing this with a few people, it is clear that there are places where this is OK, but those cases are limited[2].  Generally, a MASQUE proxy provides traffic mixing for anonymization, ensuring that its active clients collectively form a loose anonymity set.  This is not achieved if data is only forwarded.

It seems like encryption is trivial.  In addition to replacing connection IDs on between the client and proxy, the remainder of the packet could be encrypted.  This does not need to include integrity protection as the underlying packet already has adequate end-to-end protection.  All we would need is obfuscation.

Key agreement is trivial.  Clients and proxies could send each other keys.  One key per connection ID might work, or - better still - the keys can be derived from a shared secret using a KDF that uses the connection ID as input.  The trick is in finding an encryption scheme that is sufficient strong and not subject to trivial attacks.  For example, a simple application of AES-CTR with a fixed nonce is not sufficient as it would allow an adversary to find the XOR of plaintexts by XORing ciphertexts.

A scheme that *might* work here is one that we can borrow from QUIC's packet protection:

Each packet is formed from three components: the semi-fixed first byte, a connection ID, and a protected payload.  The protected payload is high entropy, being comprised of ciphertext and is anywhere from 20 to 65506 bytes.  This payload can be split into two, with a 12 byte sample being used as a nonce for AES-CTR.  The remainder of the payload, plus part of the first byte, could then be protecting using AES-CTR.  The remaining 8+ bytes could again be sampled again as a nonce to protect the first sample.


first = packet.take(0)
cid = packet.take(cid_length)
sample = packet.take(12)
remainder = packet

// Keys might be stored for the connection ID or calculated something like this:
k1 = KDF(key=secret(cid), input=("k1" || cid))
k2 = KDF(key=secret(cid), input=("k2" || cid))

e_remainder = AES-CTR-ENC(key=k1, nonce=sample, pt=remainder)
e_first = AES-CTR-ENC(key=k1, nonce=(sample - 1 or something like that), pt=first)
e_sample = e_first ^ (AES-CTR-ENC(key=k2, nonce=e_remainder[0:12], pt=[0]) & 0x1f)
e_packet = e_first || replacement(cid) || e_sample || e_remainder


This is not an ideal design, but it seems like a reasonable start.  

An obvious problem is that it breaks down a little bit on very small packets.  A 12 byte sample is probably fine, but sampling the remain 8 bytes from a 20 byte packet means sending far less than 2^32 packets to avoid a noticeable chance of a collision.  You could sample the first byte as well, but that only provides a few more bits.  More on this in a follow-up.

Cheers,
Martin


[1] A few people have noted that timing tends to be a dead giveaway here, as does packet size.  I have some ideas about how that might be managed, but let's start with the basics.

[2] For example, some have claimed that the two-hop proxying mode (see https://intarchboard.github.io/draft-obliviousness/draft-kpw-iab-privacy-partitioning.html#figure-5) only requires one lot of encryption.  I'm not sure that this is true unless you extend trust in one proxy beyond not conspiring with the other proxy to also include it *not* monitoring traffic from the more remote peer (the client for proxy B or the server for proxy A).