Re: Packet number encryption

[Jana Iyengar <[e-mail]>]

Privacy-protection can't be a user choice, for the reasons others have
noted on this thread.

That said, my primary argument is for encryption to avoid ossification. Not
that it matters now, but I'll note that much of GQUIC's original motivation
for encrypting headers was to avoid ossification.

I'll reiterate that fields we expose will get ossified and there are
long-term ecosystem effects to this. Let me illustrate this with precisely
the packet number field. Middleboxes commonly assume that a TCP flow can
only handle packets in-order. This assumption comes from the fact that TCP
implementations get poor performance when packets are reordered. This was
definitely true for implementations of TCP, but that is TCP's problem, not
the network's. However, almost all load-balancers I know of now will pin
all packets within a TCP flow to one path, leading to sub-optimal
performance in the network, and destroying incentives for the endpoints to
deploy reordering-resilient TCP implementations (even though there are
plenty of ways of doing this.)

Exposing QUIC's packet number field (as any field) is likely to have
similar consequences and a similar ecosystem arc.


On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich <[e-mail]> wrote:

> > Optional security tends to devolve to non-secure.
>
>
>
> That’s a great aphorism.  And sadly all too true.
>