Re: Greasing more of QUIC

[Martin Thomson <[e-mail]>]

On Thu, Dec 7, 2017 at 8:11 PM, Brian Trammell (IETF) <[e-mail]> wrote:
> hi Martin,
>
>> On 7 Dec 2017, at 06:03, 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
>
> First, I'll note that draft focuses on runtime adaptations: how can we scramble the wire image to resist analysis by vendors who will implement the results of that analysis in ways that might break future QUIC versions by dropping packets? This is only part of the space of mitigations available to us. There are also design- and deployment-time adaptations: exercising the version negotiation mechanism, for instance, by making the V2 header beyond the invariants gratuitously incompatible with the V1 header and deploying it very, very soon after V1.

Right.  And I still think that's a better general defense.

> When you said "this got lengthy", what I was hoping I'd see here, and didn't, is an explicit statement of the threat model the greasing we apply is meant to counter. "Ossification", yes, great, but in order to be able to evaluate the tradeoffs (especially between XOR and FFX), we need to get a bit more specific about what that means.
>
> I can think of a couple of axes along which we can classify these models:
>
> (1) Adversary intent: what is the middlebox trying to do?

I don't think that intent matters here.  One of the things I've
learned from TLS that attempting to discern intent is like trying to
comprehend Lovecraft's Deep Ones.  It's a short trip from there to an
asylum.

Your next two points I consider to be points on a spectrum.  The
biggest problem is the one you alluded to above.  The middlebox is
deployed and is inflexible.  It can be perfectly capable,
understanding everything there is to understand about the protocol
short of getting session keys, but that doesn't mean that changing
anything is possible.  Even if the upgrade pace of the middlebox is
rapid - and our experience with TLS suggests the opposite - nothing
safeguards flexibility better than being flexible.

As I said, I think that the best we can do within any single version
of the protocol is to force middleboxes into stateful inspection if
they intend to look at version-dependent traits.  This is confounded
by the fact that even if a middlebox does stateful inspection, they
won't necessarily see the version due to the possibility of connection
migration.  That said, as long as the number of packets required to
prime stateful inspection exceeds or equals the number of packets that
are required to correctly recover the version, this could be
successful.  Ideally, learning version is a prerequisite for recovery.

> Greasing is of most utility, IMO, when it is used to prevent lazy, somewhat-competent middlebox creators with access to but little interest in reading the specs from expanding the set of invariants beyond those which we prescribe, whether intentionally or unintentionally (indeed, a non-lazy adversary working to intentionally expand the set of invariants would just send a pull request on the invariants doc. :) ).

That is more proactive than I'd look for.  There's no business
motivation for worrying about protocols that aren't deployed.
Middlebox vendors definitely aren't stupid or lazy (notable exceptions
aside).  They implement what they need to, and read the specs as
necessary.  But what's deployed matters.  That's where we get into
trouble.  The middlebox that has an "allow HTTPS" policy learns to
examine flows more closely when people start using TLS over port 443
for other protocols to circumvent that policy.  When they look too
closely or too incautiously (see for example
https://arxiv.org/pdf/1607.01639.pdf), we experience bizarre
breakages.

The point here is to increase the cost of the sort of casual,
stateless inspection that can be destructive to the point that
stateful inspection is more viable.  Either that or encourage the use
of techniques other than looking at packets.

> Doing something to protect the ability to expand/change the location and semantics of the packet type switching mechanism and the packet number space and encoding in future versions seems like it's worth doing. Attempting to make these mechanisms resistant to analysis, though, doesn't seem like it has a benefit commensurate with effort and proneness to error.

The only analysis I'm looking to guard against is correlation across
migrations.  Using an unpredictable key has that advantage.  (It also
removes a bunch of really ugly properties from the current
mitigation.)