Re: Getting to consensus on packet number encryption

[Christian Huitema <[e-mail]>]

If we are in the business of repeating our positions, so be it. I am
pretty much on the same line as Patrick and others:

1) Privacy is not optional. And yes, removing "linkability through PN"
is important, because when the connection ID and the source address also
change, the only other cue for linkability is timing. Timing can be
addressed by having overlapping connections.

2) Packet number encryption is the simplest of the many options
presented so far. It is in particular much simpler to implement than the
"predictable offset" scheme presented in previous drafts.

3) I am happy to discuss alternatives that appear simpler to implement
in hardware, but so far the only plausible alternative is to insert an
extra nonce in the packet header. Given birthday paradoxes and all that,
this probably requires 8 extra bytes of overhead per packet, which is
not very attractive.

-- Christian Huitema


On 4/4/2018 4:42 PM, Praveen Balasubramanian wrote:
>
> What is the privacy issue if you are not doing migration? Migration +
> PNE (or multiple PN spaces) should go hand in hand.
>
>  
>
> *From:* QUIC [mailto:[e-mail]] *On Behalf Of *Mikkel
> Fahnøe Jørgensen
> *Sent:* Wednesday, April 4, 2018 4:40 PM
> *To:* Praveen Balasubramanian <pravb=[e-mail]>;
> Ian Swett <ianswett=[e-mail]>; Mark Nottingham
> <[e-mail]>
> *Cc:* Lars Eggert <[e-mail]>; IETF QUIC WG <[e-mail]>;
> Mirja Kühlewind <[e-mail]>
> *Subject:* RE: Getting to consensus on packet number encryption
>
>  
>
> Without pro / con anything:
>
>  
>
> Optional privacy does not work. In part it cannot be retrofitted when
> the need arise, in part it can be incriminating to enable.
>
>  
>
> On 5 April 2018 at 01.22.38, Praveen Balasubramanian
> (pravb=[e-mail]
> <mailto:pravb=[e-mail]>) wrote:
>
>     Make PNE (and hence connection migration) an optional negotiated
>     extension in V1 
>