Re: Hardware acceleration and packet number encryption

[Eric Rescorla <[e-mail]>]

On Sat, Mar 24, 2018 at 9:41 PM, Subodh Iyengar <[e-mail]> wrote:

> When we were first discussing pne, we proposed that the tag be used as the
> IV for the ctr operation. The pr samples encrypted data in the packet. Did
> we change that for a reason?
>

I believe that's my alternative #1 and PR#1079.


Would that help alleviate the buffering of the stream data? Because tag is
> always the last thing in the packet.
>

I will let Manasi answer this.


-Ekr


>
> Subodh
>
>
> On Mar 25, 2018, at 2:56 AM, Eric Rescorla <[e-mail]> wrote:
>
>
>
> On Sun, Mar 25, 2018 at 2:09 AM, Deval, Manasi <[e-mail]>
> wrote:
>
>> From talking to several of the folks last week, I understand that
>> unlinkability is the goal of this protocol and there may be some
>> flexibility in how that can be achieved.
>>
>>
>>
>> Christian’s e-mail has a detailed list of options.  Here is the list of
>> favored options as I understand them.
>>
>>
>>
>> 1.      Packet number encrypted as current suggestion - The current
>> proposal for PR 1079, uses a two stage serialized approach such that the
>> stream header(s) and payload(s) need to be encrypted and the outcome of
>> encryption forms the nonce of the packet number encryption.
>>
>>
>>
>> 2.      Packet number encrypted alternative 1 - One of the ideas
>> suggested was to encrypt the stream header(s) and payload(s) with the
>> packet number as nonce, but have an additional nonce in the clear to
>> encrypt the packet number. A scheme like this can allow for these two
>> encryption operations to occur in parallel. This still has the issue of
>> serialization in decrypt.
>>
>>
>>
>> 3.      Packet number encrypted alternative 2 – Another option is to
>> generate 2 IVs – one for PN and the other for stream header(s) and
>> payload(s). The nonce can be a random value in the clear. This allows us to
>> encrypt and decrypt the two fields in parallel. The packet number is
>> encrypted so it also solves the ossification problem. Another variation of
>> this is to generate a single IV but use one part of it to encrypt the PN.
>>
> Neither of these alternatives seems ideal. Once you are carrying an
> explicit per-packet nonce, you might as well concatenate the payload and
> the PN and encrypt them together. The will require the least amount of
> nonce material.
>
> -Ekr
>
> 4.      PN in the clear – this is a complex scheme and in the discussion
>> with Ian, Jana and Praveen, they seemed to think this may be ok. If folks
>> think this is implementable, then we may need to find an alternate solution
>> for ossification.
>>
>>
>>
>> Thanks,
>>
>> Manasi
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* Eric Rescorla [mailto:[e-mail]]
>> *Sent:* Saturday, March 24, 2018 3:18 PM
>> *To:* Mikkel Fahnøe Jørgensen <[e-mail]>
>> *Cc:* Kazuho Oku <[e-mail]>; Deval, Manasi <
>> [e-mail]>; Christian Huitema <[e-mail]>; IETF
>> QUIC WG <[e-mail]>
>> *Subject:* Re: Hardware acceleration and packet number encryption
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Mar 24, 2018 at 9:35 PM, Mikkel Fahnøe Jørgensen <
>> [e-mail]> wrote:
>>
>> AERO: I did not read all of it, but it does indeed sound esoteric.
>>
>> It can do two things of interest: reduce space used by packet numbers,
>> and presumably fix the encryption issue.
>>
>>
>>
>> However, it has a W parameter which is the limit of reordering which is
>> default 64 and recommended at most 255 for security reasons. This is way
>> way too low (I would assume) if packet clusters take multiple transatlantic
>> paths.
>>
>>
>>
>> That's just a function of how the packet numbers are encoded. It's not
>> difficult to come up with a design that tolerates more reordering.
>>
>>
>>
>> -Ekr
>>
>>
>>
>>
>>
>> If we accepted such a limit, I could very trivially come up with an
>> efficient solution to PN encryption. Since we cover at most 64 packets, we
>> only need a 5 bit packet number and reject false positives on AEAD tag. To
>> simplify, make it 8 bits. The algorithm is to AES encrypt a counter similar
>> to a typical AES based PRNG. Then, for each packet take one byte from the
>> stream and use it as packet number. The receiver creates the same stream
>> and maps the received byte to an index it has. It might occasionally have
>> to try multiple packet numbers since the mapping is not unique. Longer
>> packet numbers reduce this conflict ratio. To help with this detection some
>> short trial decryption might be included. The PN size can be extended as
>> needed.
>>
>>
>>
>> The cost of doing this is much lower than direct encryption for as
>> proposes in PR because 1) a single encryption covers multiple packets, 2)
>> the encryption can be parallelised resulting in a 4-5 fold performance
>> increase. Combined this results in sub-nanosecond overhead for AES-NI.
>>
>>
>>
>> However, you have to deal with uncertainties which is why this isn’t a
>> very good idea unless you have some very good knowledge of the traffic
>> pattern. It also complicates HW offloading, but I don’t see why it couldn’t
>> be done efficiently.
>>
>>
>>
>>
>>
>> Mikkel
>>
>>
>>
>> On 24 March 2018 at 17.26.47, Eric Rescorla ([e-mail]) wrote:
>>
>> 3. A more exotic solution like AERO (https://tools.ietf.org/html/d
>> raft-mcgrew-aero-00#ref-MF07
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmcgrew-2Daero-2D00-23ref-2DMF07&d=DwMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=Kqui4PrKKRuP58njW3vlK_ZPgcQX0TQ9iXVtGY1Kp30&s=GthDylmhvmHUnMvnjBT05qJT9VrOTknvVoMbdC7ObLo&e=>
>> )..
>>
>>
>>
>>
>>
>
>