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

[Kazuho Oku <[e-mail]>]

2018-04-06 19:40 GMT+09:00 Martin Thomson <[e-mail]>:
> On Fri, Apr 6, 2018 at 7:14 PM, Kazuho Oku <[e-mail]> wrote:
>> One way to minimize the impact could be to suggest certain amount of
>> connections (e.g., 5%) to gratuitously migrate to a new tuple just once,
>> right after the connection is being established.
>
> I like this idea.  Do it rarely, but with a high enough probability
> that it is noticed.
>
> I don't think that we need to specify it, rather permit it (maybe with
> observations about the costs of doing it too often), then establish a
> convention.  We can reach enough of the client population in this
> group that we can probably coordinate effectively such that we reach a
> common enough proportion.  Add migrate-after-idle as the current PR
> suggests, which has a much lower chance of expanding state and I'm not
> seeing much need for "grips".

+1 to all the comments. The approach has very small (not if the least)
impact on existing QUIC implementations, middleboxes, and the
specification.

>
>> If we specify that way, we can assume that the impact on the NAT will be
>> having 5% more flows.
>
> 5% more only during the first timeout interval (whatever that is) and
> thereafter no more with this design.

Thank you for the correction. Nice catch :-)

-- 
Kazuho Oku