Re: Getting to consensus on packet number encryption

[Eric Rescorla <[e-mail]>]

On Wed, Apr 4, 2018 at 5:44 PM, Christian Huitema <[e-mail]>
wrote:

> 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.
>
8 seems pretty close to the line unless we are going to rekey *very*
frequently. Probably more like 12 bytes.

In any case, I concur that we should do PN encryption and IMO PR#1079 is
the best -- or at least close to the best -- design we have. I would prefer
to land it, and then if we find something better later, we can improve it
then.

-Ekr

-- 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] <[e-mail]>] *On
> Behalf Of *Mikkel Fahnøe Jørgensen
> *Sent:* Wednesday, April 4, 2018 4:40 PM
> *To:* Praveen Balasubramanian <pravb=[e-mail]>
> <pravb=[e-mail]>; Ian Swett
> <ianswett=[e-mail]>
> <ianswett=[e-mail]>; Mark Nottingham <[e-mail]>
> <[e-mail]>
> *Cc:* Lars Eggert <[e-mail]> <[e-mail]>; IETF QUIC WG
> <[e-mail]> <[e-mail]>; Mirja Kühlewind
> <[e-mail]> <[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]) wrote:
>
> Make PNE (and hence connection migration) an optional negotiated extension
> in V1
>
>
>