Re: Greasing more of QUIC

[Martin Thomson <[e-mail]>]

On Thu, Dec 7, 2017 at 6:38 PM, Jana Iyengar <[e-mail]> wrote:
> I suspect the mechanisms here are a bit heavyweight for the greasing model I
> had in mind.

Not really, see below.  I included a more heavyweight option to show
the range of options that I think we have in front of us.

> The model I had in mind was that a middlebox that cared to read
> the spec would be able to interpret the packet types, but it couldn't from
> simply looking on the wire. I don't think we want to use a per-connection
> key, as load balancers will want to know the packet type and won't have the
> connection keys. Visibility for middleboxes is the reason we didn't encrypt
> the packet types in the first place.

I want to challenge this last point.  I don't think that we've
established a good reason for middleboxes to have visibility into the
short header types, and anything that we do for the long header can
probably only be based on the spec in exactly the way you describe -
we never use anything other than a fixed key to protect packets with
long headers.

I'm personally more interested in packet numbers than packet types though.

> If you wanted to do a PRP based on this weaker model you'd end up using a
> known key per version, documented in the draft. Of course, the problem here
> is that you don't grease any values since the same permutation is used for a
> given version, and the permuted packet types remain fixed for the version.

One property I'm looking for us to guarantee is that no value goes
unused, even if the actual underlying value is the same.  That means
per-connection permutations.

> You could combine the version-specific key with something from the packet,
> perhaps the packet number (not the entire 64-bit number, only the visible
> part on the wire, for stateless middlebox operation), to permute the packet
> type, giving you more useful greasing.

That's effectively what this does.  The draft (I'm beginning to regret
doing that now) mentions using connection ID, as input to the key.  I
should have added both packet number and even the ciphertext.  You
will observe that XOR is very close to what you describe if you take
packet number as input to the key derivation (XOR and additional
modulo N are very similar).  If you took connection ID and packet
number in the following form, you get almost exactly what you
describe.

E(x) = m ^ connection_id ^ packet_number

> This is just me thinking off the top of my head, but that's roughly what I
> had in mind. It obviously assumes a weaker form of greasing than the ones in
> your draft is desirable.

That is a reasonable position.  Types will never really benefit much
from anything more complex.  For packet number, I wanted something
stronger to support the ideas in the final section.