Re: Greasing more of QUIC

[Jana Iyengar <[e-mail]>]

Martin,

Thanks for writing this up! One main thought as I read the draft.

I suspect the mechanisms here are a bit heavyweight for the greasing model
I had in mind. 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.

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.

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.

Alternatively, for this model of greasing I have in mind, all you need is
to cover the entire space of possible types, not encrypt the packet type. A
simple method would be, for instance, to use the result of (packet number %
packet type). This has the unfortunate property that the packet type will
basically start at a random point in its space but increment by one during
the bulk of the connection, since most packets will use a single packet
type (short header with 2-byte packet number). We can fix that somewhat by
adding a random additive, also documented per version, after the mod
operation: (packet number % packet type + random additive). This has the
property that for consequent packets with the same packet type but
increasing packet number, the resulting packet type will start at a random
value per connection (since initial packet number is random) , and will
increase by a fixed value for any given version.

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.

Thoughts?
- jana

On Wed, Dec 6, 2017 at 9:03 PM, Martin Thomson <[e-mail]>
wrote:

> I've sort of promised a few times, to a few people, that I'd write up
> the state of play regarding greasing.  I just did that and it got
> somewhat lengthy.  So I decided that I'd put the words in a draft.
> Sorry.  That's what you get when publishing drafts gets easier...
>
> https://datatracker.ietf.org/doc/html/draft-thomson-quic-grease
>
> Based on this, I'm a little more enthusiastic about protecting packet
> numbers, mainly for the secondary benefits that come with it.  But
> I'll let others reach their own conclusions about that.
>
>