Re: Privacy holes (was: Re: Getting to consensus on packet number encryption)

[Martin Thomson <[e-mail]>]

On Fri, Apr 6, 2018 at 12:06 PM, Kazuho Oku <[e-mail]> wrote:
> If I understand correctly, Christian's concern is that some middleboxes
> might only create a hole if the first packet sent by a client (using a new
> port) looks like a Initial packet.

Oh, I didn't get the same impression, but it does seem like a valid
concern.  The idea I had was to have clients migrate often enough that
those middleboxes will see those migrations and not incorrectly assume
that flows have to start with Initial packets.

Of course, migrating often like this might not provide enough
incentive to avoid that practice because clients will likely make new
connections when the old one fails.  But given that this sort of
failure probably involves a timeout before the repair, it's probably
still noticeable enough to generate support tickets (and incentive to
allow the migration to pass).

Existing middleboxes that pass UDP will be fine, so we at least have
that in our favour.

> 1. frequent gratuitous migration by clients, so that middlebox vendors can
> notice that there design is wrong prior to shipping it

That is what this was angling for.  The question being how frequent.

> 3. mimic 0-RTT handshake when gratuitously switching to a new UDP flow
> (depends on #1262)
>
> 1 and 2 have been discussed on this thread. I haven't yet seen 3 being
> discussed.

It has been suggested a few times elsewhere.  The question is how far
you go: do you send Initial and Handshake packets that use the
handshake packet protection and carry apparently real ClientHello and
ServerHello messages?  Do you restrict the flow of packets to match
0-RTT?

> The concerns so far being raised for 1 is that NATs might run out of
> unassigned ports and that switching to a new path might trigger the restart
> of congestion control on large-scale NATs that use multiple public
> addresses.

That is possible, but it depends on how often you attempt this.  CGNAT
does try to keep IP addresses for the same device stable.  If not,
then a congestion controller reset for relatively infrequent
migrations isn't so bad if heuristics fail.  It's only when you have
very frequent migration that the resets becomes burdensome.

> The concern so far being raised for 2 is that stateless load balancers would
> be required to decrypt the type field (or the entire packet, depending on
> how we encrypt) to determine if a packet is trying to initiate a new
> connection.

Yeah, that's hard.  Having the load balancer hit the slow path for
every packet seems pretty fatal.