Subject: Re: [quicwg/base-drafts] GREASE the packet type octet (#311)

From: ekr <[email-masked]>
Date: Tue, 06 Jun 2017 07:53:55 -0700

As I said in the meeting, I have an alternative proposed design:

- Packet has type P
- Encrypt the packet and call the last byte of the packet (the auth tag) T
- Set the new packet type to be P ^ (T & 0x7f)

This randomizes the packet type without placing any special requirements on the construction of the code points.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/311#issuecomment-306511671

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 06 Jun 2017 08:17:52 -0700

Discussed in Paris; generally agreed to be a good thing. 

Jana and Ian to check to see if this makes migration from Google QUIC easy/hard.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/311#issuecomment-306519525

---

From: ekr <[email-masked]>
Date: Tue, 06 Jun 2017 08:19:01 -0700

@huitema points out that we might want to have a keyed permutation because any static permutation is easily degreased. The observation here is that you can have a key that's shared across all of the connections, because we're not really worried about the middlebox connecting to the server and extracting the key for the transformation. With that in mind, here's an alternate keeed proposal.

```
1. Server generates a key K_static which it uses for all connections.
2. Packet has type P and last byte T
3. The server delivers K_static in its first flight.
4. For every packet, you compute P' = P ^(PRF(K, T) & 0x7f) where
    K = 0 for initial packets
    K = K_static for other packets.
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/311#issuecomment-306519885

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 06 Jun 2017 22:38:18 -0700

@ekr I am afraid that the approach might not work well with a deployment that uses either connection ID or 5-tuple for load balancing, depending on the type of a packet.

In the past, we have discussed of deployments that would use some bits of a connection ID to route a packet to the correct server sitting behind a load balancer (or to the correct POP within an anycast deployment). Note that such a load balancer will typically not maintain any state of a QUIC connection.

OTOH, I also anticipate that even in a deployment that does connection ID-based load balancing, you might want to route packets to backend servers based on the 5-tuple during the handshake. This is for avoiding attacks targeting a specific server behind a load balancer. Note that processing of handshake packets could be much more computationally intensive due to public-key operations when compared to other types of packets.

The issue with the proposed approach is that it is impossible for a stateless load balancer to determine the correct type of the packet, since whether `K=0` or `K=K_static` should be used depends on the state of the connection. Therefore, with the proposed approach, it becomes impossible to change how the packet is load balanced depending on the type of a packet.

Am I missing something?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/311#issuecomment-306691925

---

From: ekr <[email-masked]>
Date: Tue, 06 Jun 2017 22:42:04 -0700

Hmm.. I see your point. That is a problem. There's probably some way around that (one idea would be to steal one more bit for that), but I'll have to think about the best approach.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/311#issuecomment-306692436

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 06 Jun 2017 23:10:10 -0700

Thank you for the response. I agree that stealing a bit could fix the problem.

Reconsidering this, it seems to me that there is another issue (sorry for the fuss).

My understanding is that some load balancers start streaming packets to the correct port before seeing the end of the packet. Making the actual type depend on the final octet of a packet prevents us from using such a load balancer.

Would it be possible to use an octet that exists at the beginning of the packet for greasing?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/311#issuecomment-306696547

---

From: ekr <[email-masked]>
Date: Tue, 06 Jun 2017 23:56:43 -0700

The problem is that then if you are not encrypting, than those bytes are not random. @larseggert suggested that this shouldn't really be a big deal

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/311#issuecomment-306704621

---

From: Christian Huitema <[email-masked]>
Date: Wed, 07 Jun 2017 00:14:57 -0700

The greasing requires some kind of "obfuscation" or "encryption" of the packet type. Simple obfuscation would be to combine the packet type with some fields in the packet, and would not require any "key". Problem with that is that middleboxes will quickly learn the obfuscation algorithm, and then reverse it. So if we want to actually grease, we need to use some kind of key-driven encryption.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/311#issuecomment-306708010

---

From: Christian Huitema <[email-masked]>
Date: Wed, 07 Jun 2017 00:19:08 -0700

Yesterday, we briefly mentioned a potential solution in which the packet type would be encrypted with a key known by the load balancer. Of course, having the same key used by the load balancer and every client does not work. The middleboxes would just have to set a connection to the service to learn the key. In any solution like that, the key has to be specific to a single client. It will have to depend on the connection ID, something like f(ConnectionID, local secret). 

The good part is that if we do something like that, we can also encrypt the packet number.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/311#issuecomment-306708921