Subject: Hardware acceleration and packet number encryption

From: Christian Huitema <[email-masked]>
Date: Sat, 24 Mar 2018 12:18:49 +0000

There were a number of corridor discussions of hardware acceleration of
Quic during the IETF meeting. In particular, Manasi Deval asked many of
us our opinion about packet number encryption. From the conversation, I
understand that packet number encryption as specified would make
acceleration of Quic difficult to implement on Intel's hardware. She was
trying to convince us that privacy is an unattainable goal, and that we
should just as well ditch the linkability requirement in order to
facilitate hardware acceleration. I would much rather see the issue
debated in the open than in a series of 1-1 conversations. After all,
open discussion is a key tenet of the IETF.

When I look at the potential trade-offs, I see the following, which have
been proposed at different times:

1- Single sequence number of all paths, starting at 0 (or 1), numbers
sent in clear text;

2- Single sequence number for all paths, starting at 0 (or 1),
obfuscated via a different random offset for each path. (We will assume
that the offset is tied to the connection ID used in the path.)

3- Single sequence number for all paths, starting at 0, combined with
packet number encryption as specified in PR1079.

4- Separate sequence number for each path, starting at 0 (or 1), numbers
sent in clear text. (We will assume that the there will be a separate
connection ID per path, so the combination of connection ID and sequence
number is unique.)

5- Single sequence number for all paths, starting at 0, combined with a
simpler packet number encryption than specified in PR1079.

These options have different costs in term of privacy (linkability),
ossification, hardware acceleration, and software complexity.

Having a single sequence number sent in clear text on all paths (option
1) makes it very easy to correlate different paths. We also know that
the random offset solutions (option 2) only provide a modest defense
against linkability if the activity on two paths overlaps. It would
definitely now be adequate for multipath, and it is probably not
adequate either for the "make before break" variants of path migration.
The other variants prevent linkability either by encrypting the sequence
number, or by using different sequence numbers on different paths.

Only encryption prevents ossification. If we send packet numbers in
clear text (option 1 or 4), or even if we use simple obfuscation (option
2), middle-boxes can find the position of the sequence numbers by
comparing the headers of successive packets. There are high chances that
we would then see half-brained schemes, such as delaying packets for
reordering, or enforcing some kind of sequence range. This is a classic
ossification scenario.

Packet number encryption as specified in PR 1079 relies on a two-pass
algorithm. First encrypt the packet, then use the result of the
encryption as a nonce when encrypting the sequence number. It seems that
this two-pass approach forces double buffering in the acceleration
hardware. Opinions vary about how bad that is, and hardware specialist
should really explain the problem if they believe it is important. There
may be different ways to encrypt the packet number (option 5) that do
not require double buffering, but this is merely a theoretical
possibility. Those schemes are not specified.

Using separate packet number for each path would prevent linkability and
facilitate acceleration, but it makes the protocol and the software
significantly more complex. It requires using different keys or IV for
different paths, and it also require management of several sequence
number spaces. Since the packet with number "3" on path 1 will not be
the same packet as number "3" on path 2, the acknowledgements will need
to be tied to a path, either implicitly because they are sent on that
path, or explicitly by tagging the ACK frame with a path specific
connection ID. We would probably need both, because in migration
scenarios it is useful to send on the new path acknowledgement of
packets received on the old path. This kinds of complexity breeds bugs
and interoperability issues. Plus, this solution does not prevent
ossification, as discussed above.

My personal preference is to start with PR 1079, which is a sound
solution to all problems except acceleration. The acceleration issue
should be discussed in the open, and we probably want to hear from more
than one possible hardware vendor. Do all hardware makers have an issue
with double buffering, or is this just specific to one particular
architecture? Is it worth exploring alternative packet number encryption
techniques that would not have the double buffering issue?

-- Christian Huitema

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sat, 24 Mar 2018 12:57:36 +0000

see reply below

On Sat, Mar 24, 2018 at 1:19 PM Christian Huitema <[email-masked]>
wrote:
...

>  packet number encryption as specified would make
> facilitate hardware acceleration.

I also believe that privacy is a wild goose chase. There is no reason to
expose more
necessary, but we risk limiting the protocol design more than it is worth.

Even without HW accellaration, modifying a buffer in-place can affect CPU
cache
performance and synchronization on multi-core systems, and it adds latency
- which
might be small in todays typical use case, but not necessarily in special
cases or in the future.
Crypto might get faster, but possibly by adding parallelism with higher
latency and packet number
encryption cannot be parallized.

> number spaces.

This is largely what I have proposed in Segmented Packet Numbers
https://github.com/quicwg/base-drafts/issues/1105

The idea is that the packet number itself is larger than the wire
transmission. The high bits are hidden from the packet header
but are included internally and in ACK frames (using some varlen encoding).
This will naturally sort ACK's per path and give
a largest ACK'ed per path. There would be no total ordering which might be
a problem with some designs relying on
"everyting send before" such as new path id's. It wold allow for packet
numbers larger than 64 bit. In ACK only the first packet number in a block
is sent explicitly so there is a natural compression.

Yes, it complicates the design slighty but it gives you a lot of automatic
per path ACK RTT data and sidesteps the issue with encryption
and also provides easy monitoring to middleware - data that they could
infer less reliably on their own in most cases, so no loss of privacy.

I like the simplicity of packet number encryption but due to how it needs
to be implemented I'm no longer believing that this is a great idea.

Mikkel

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sat, 24 Mar 2018 13:29:13 +0000

BTW: segmented packet numbers also provides convenient support for
multi-core packet generation because each core could have its own segment,
even on the same path. It can encrypt without conflict with peer cores on
the same connection and without inducing false packet reordering. As
mention in the github issue a sender can also alternate between segments to
defend against optimistic ACK without introducing packet gaps. Thus, all
gaps are losses or reodering.

On Sat, Mar 24, 2018 at 1:57 PM Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

> but are included internally and in ACK frames (using some varlen
> encoding). This will naturally sort ACK's per path and give

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 24 Mar 2018 14:59:13 +0100

Hi Christian, 

Thank you for starting the discussion. My comments inline.

> facilitate hardware acceleration.

I would argue that packet number encryption and hardware offloading are not exclusive goals.

The only reason the current proposed form of packet number encryption is requiring two-path encryption is because it uses packet number as a nonce as well.

That means that we can attain both goals for example by using an explicit nonce and sending packet number as encrypted payload. The downside of such approach will be that per-packet overhead will increase (likely by 8 bytes or so) and that we would be required to discuss how to tackle nonce-reuse.

I am not sure if providing support for **current form of** hardware is necessary, but assuming that we decide so, I'd prefer using explicit nonce or any other way that provides both one-path encryption and packet number encryption.

> I would much rather see the issue
> significantly more complex.

Actually, I think that packet number encryption makes multi-path easier.

Both AES and chachapoly allows up to 96-bit nonce, while we only use 64 bits. Remaining 32 bits are left zero. In that space, we can store path-id (that is incremented by one for every new path) to avoid nonce-reuse.

By doing so, each path can start with packet number zero while using the same encryption key for all paths.

> It requires using different keys or IV for

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 24 Mar 2018 16:25:55 +0000

I think it would probably be useful to ask this question in two pieces.

1. Is PN something we would want to do if it were free from a performance
perspective?
2. What are the technical options for building PN encryption, and then are
the costs acceptable?

My answer to #1 is "yes", but I imagine there are others who disagree. So
we should probably get that out of the way.

#2 obviously requires some technical thought. I am aware of three major
design options:

1. One like the one in PR#1079 where you separately encrypt the PN.
2. One with an external nonce like the one Kazuho describes.
3. A more exotic solution like AERO (
https://tools.ietf.org/html/draft-mcgrew-aero-00#ref-MF07).

PR#1079 has the disadvantage of double buffering.

An external nonce is possible but is a bit tricky. It is critical it be
nonrepeating, and if you randomly generate n-bit nonces, then the collision
bound gets scarily large before 2^{n/2}. So, for instance in Kazuho's
suggestion, you would be able to encrypt well less than 2^{32} packets
before you needed to rekey in some way, which is pretty suboptimal. Even 96
bits is not great. The difficulty of getting this right is one reason why
TLS 1.3 changed from TLS 1.2's explicit nonce to an implicit nonce based on
the counter. The canonical way to generate a sequence like this is to feed
a counter into a pseudo-random permutation, but our standard efficient PRP
is AES, and that works on 128 bits. I'm asking cryptographers if they have
a better plan.

Finally, we could use a more exotic solution like AERO. The draft has
details, but roughly speaking, it's like an extension of AEAD which also
takes the sequence number as an input on encryption and then returns it on
decryption, so you don't need a separate sequence number or nonce.
Obviously this is pretty much designed for our purpose, but it's a
relatively new construction and so I don't know how much analysis there has
been of its security. In addition, while it's based on AES-CTR, I don't
know what the performance is like in hardware.

-Ekr

On Sat, Mar 24, 2018 at 1:59 PM, Kazuho Oku <[email-masked]> wrote:

> The only reason the current proposed form of packet number encryption is
> requiring two-path encryption is because it uses packet number as a nonce
> as well.
>
>
> That means that we can attain both goals for example by using an explicit
> nonce and sending packet number as encrypted payload. The downside of such
> approach will be that per-packet overhead will increase (likely by 8
> bytes or so) and that we would be required to discuss how to tackle
> nonce-reuse.
>
>
> I am not sure if providing support for **current form of** hardware is
> necessary, but assuming that we decide so, I'd prefer using explicit
> nonce or any other way that provides both one-path encryption and packet
> number encryption.
>
>
> significantly more complex..
>
>
> Both AES and chachapoly allows up to 96-bit nonce, while we only use 64
> bits. Remaining 32 bits are left zero. In that space, we can store
> path-id (that is incremented by one for every new path) to avoid
> nonce-reuse.
>
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sat, 24 Mar 2018 12:52:47 -0400

Below ...

On 24 March 2018 at 14.28.21, Mikkel Fahnøe Jørgensen ([email-masked])
wrote:

Both AES and chachapoly allows up to 96-bit nonce, while we only use 64
bits. Remaining 32 bits are left zero. In that space, we can store
path-id (that
is incremented by one for every new path) to avoid nonce-reuse.

This is the same concept as segmented packet number except the lower PN
bits are encrypted. But if you send three packets in a row on the same path
with a new path id, it is not very difficult to make a qualified guess
about the unencrypted packet number. So why bother encrypting in the first
place using this approach?

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 24 Mar 2018 19:21:19 +0000

2018-03-24 17:52 GMT+01:00 Mikkel Fahnøe Jørgensen <[email-masked]>:
> bits. Remaining 32 bits are left zero.. In that space, we can store path-id
> (that is incremented by one for every new path) to avoid nonce-reuse.
>
>
>
> This is the same concept as segmented packet number except the lower PN bits
> are encrypted. But if you send three packets in a row on the same path with
> a new path id, it is not very difficult to make a qualified guess about the
> unencrypted packet number. So why bother encrypting in the first place using
> this approach?

That's an interesting question. I would argue as follows:

>From what I understand, the two primary benefits of packet number
encryption are linkability hardening and ossification prevention.

Sending packet number in clear, with always starting from a fixed
number sounds like easing ossification.

Starting from zero on each path also seems like giving observer a
signal of new path being created (with the current approach or packet
number encryption, it is not easy to see if a newly observed path is
actually a new path or not).

Lastly, switching to a new path when unnecessary could lead to
performance degradation, since loss recovery and congestion control
are usually managed per-path. You can of course map N paths to one
loss-recovery/congestion-control, however doing so complicates the
implementation.

-- 
Kazuho Oku

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sat, 24 Mar 2018 17:35:26 -0400

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.

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 ([email-masked]) wrote:

3. A more exotic solution like AERO (
https://tools.ietf.org/html/draft-mcgrew-aero-00#ref-MF07)..

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sat, 24 Mar 2018 17:58:51 -0400

Another approach that could be explored is carry-less multiplication in the
GF(2^n) domain. This could reduce the size of required bits to make a
mapping which would be non-trivial to break. GCM uses something along these
lines for hashing, but in a 128 bit domain. My math foo is not strong
enough to say if this is a good idea. If it could be done with a CLMUL
instruction the overhead would be low and where it isn’t supported, GCM
suffers too.

One could also be less ambitious and use a seeded hash and deal with the
odd conflict, for example:
Faster 64-bit universal hashing using carry-less multiplications
https://arxiv.org/pdf/1503.03465.pdf

But both of these potential approaches probably suffer when the packet
number length drops down to 8 or 16 bits. Which is why we are back the the
encryption of an AES block that overlaps with other content leading to so
called double buffering.

On 24 March 2018 at 22.35.26, Mikkel Fahnøe Jørgensen ([email-masked])
wrote:

Mikkel

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 24 Mar 2018 22:18:26 +0000

On Sat, Mar 24, 2018 at 9:35 PM, Mikkel Fahnøe Jørgensen <[email-masked]

> way too low (I would assume) if packet clusters take multiple transatlantic

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

> 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
> 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
>
>
> 3. A more exotic solution like AERO (https://tools.ietf.org/html/
> draft-mcgrew-aero-00#ref-MF07)..
>
>

---

From: "Deval, Manasi" <[email-masked]>
Date: Sun, 25 Mar 2018 01:09:07 +0000

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.

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:[email-masked]]
Sent: Saturday, March 24, 2018 3:18 PM
To: Mikkel Fahnøe Jørgensen <[email-masked]>
Cc: Kazuho Oku <[email-masked]>; Deval, Manasi <[email-masked]>; Christian Huitema <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Hardware acceleration and packet number encryption

On Sat, Mar 24, 2018 at 9:35 PM, Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>> 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 ([email-masked]<mailto:[email-masked]>) wrote:
3. A more exotic solution like AERO (https://tools.ietf.org/html/draft-mcgrew-aero-00#ref-MF07)..

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 25 Mar 2018 02:55:03 +0100

On Sun, Mar 25, 2018 at 2:09 AM, Deval, Manasi <[email-masked]>
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.
>
>
>
> 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:[email-masked]]
> *Sent:* Saturday, March 24, 2018 3:18 PM
> *To:* Mikkel Fahnøe Jørgensen <[email-masked]>
> *Cc:* Kazuho Oku <[email-masked]>; Deval, Manasi <
> [email-masked]>; Christian Huitema <[email-masked]>; IETF
> QUIC WG <[email-masked]>
> *Subject:* Re: Hardware acceleration and packet number encryption
>
>
>
>
>
>
>
> On Sat, Mar 24, 2018 at 9:35 PM, Mikkel Fahnøe Jørgensen <
> [email-masked]> wrote:
>

---

From: Subodh Iyengar <[email-masked]>
Date: Sun, 25 Mar 2018 04:41:28 +0000

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? Would that help alleviate the buffering of the stream data? Because tag is always the last thing in the packet.

Subodh

On Mar 25, 2018, at 2:56 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, Mar 25, 2018 at 2:09 AM, Deval, Manasi <[email-masked]<mailto:[email-masked]>> 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.

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

Thanks,
Manasi

From: Eric Rescorla [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, March 24, 2018 3:18 PM
To: Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>>
Cc: Kazuho Oku <[email-masked]<mailto:[email-masked]>>; Deval, Manasi <[email-masked]<mailto:[email-masked]>>; Christian Huitema <[email-masked]<mailto:[email-masked]>>; IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Hardware acceleration and packet number encryption

-Ekr

Mikkel

On 24 March 2018 at 17.26.47, Eric Rescorla ([email-masked]<mailto:[email-masked]>) wrote:
3. A more exotic solution like AERO (https://tools.ietf.org/html/draft-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=>)..

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 25 Mar 2018 05:24:26 -0700

On Sat, Mar 24, 2018 at 9:41 PM, Subodh Iyengar <[email-masked]> 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 <[email-masked]> 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=>
>> )..
>>
>>
>>
>>
>>
>
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 25 Mar 2018 11:48:25 -0400

The tag used as IV in ECB mode for PN enceryption will use a full block
size which is 16 octets. The proposal was encrypt the tag and XOR the
result over that packet number and what follows.

If this is what is meant by “tag as IV” it is problematic for what I assume
is meant by double buffering, i.e. the need to modify the packet buffer
decryption. This is because the packet number and what follows must be
un-XORed before verification can take place.

You could keep the packet number out of AEAD, but you cannot afford to
waste the additional 16-4=12 octets or more that an AES block encryption
uses, so you a stuck with modifying the buffer post AEAD.

Finding alternative nonces won’t fix this problem. If you encrypted the
header completely separately from the body, you could do something, but
then you waste space on extra header tags.

My suggestion with GF(2^n) will not work because: even if it works in
principle (finding an ideal in GF(2^32) and multiplying a seed with packet
number modulo ideal), it is easy to brute force 2^32. Alternatively you can
do chained hashing similar to how GCM’s GHASH works but then is not a
unique mapping, but that is not better the CTR mode encryption PRNG style,
and likely slower. Why would you do this at all, if it worked? Because at
allows you to stick to encrypting only the packet number that can stay
outside AEAD and thus avoid buffer modification. But I don’t see how it can
work.

Mikkel

On 25 March 2018 at 14.25.07, Eric Rescorla ([email-masked]) wrote:

-Ekr

---

From: Christian Huitema <[email-masked]>
Date: Sun, 25 Mar 2018 09:09:26 -0700

If we are exploring research ideas, one possibility would be to use 64 bit sequence numbers, and encrypt them using a modern 64 bit cipher like SPARX (https://www.cryptolux.org/index.php/SPARX). We can exclude the PN bits from the authenticated data, since the actual sequence number is part of the AEAD nonce.  With that, 64 bit encryption of the PN and AEAD encryption of the payload can proceed in parallel. Decryption requires first decrypting the PN to initialize the AEAD nonce, but that can be done without double buffering.

Of course, the cost of that is header overhead, since the PN always occupies 64 bits. So we are trading some overhead for hardware acceleration. And we have to have some faith in the 64 bit encryption algorithm. (SPARX was suggested to me by Jean-Philippe Aumusson, the author of IPCrypt.)

-- Christian Huitema 

> On Mar 25, 2018, at 8:48 AM, Mikkel Fahnøe Jørgensen <[email-masked]> wrote:
> 
> The tag used as IV in ECB mode for PN enceryption will use a full block size which is 16 octets. The proposal was encrypt the tag and XOR the result over that packet number and what follows.
> 
> If this is what is meant by “tag as IV” it is problematic for what I assume is meant by double buffering, i.e. the need to modify the packet buffer decryption. This is because the packet number and what follows must be un-XORed before verification can take place.
> 
> You could keep the packet number out of AEAD, but you cannot afford to waste the additional 16-4=12 octets or more that an AES block encryption uses, so you a stuck with modifying the buffer post AEAD.
> 
> Finding alternative nonces won’t fix this problem. If you encrypted the header completely separately from the body, you could do something, but then you waste space on extra header tags.
> 
> 
> My suggestion with GF(2^n) will not work because: even if it works in principle (finding an ideal in GF(2^32) and multiplying a seed with packet number modulo ideal), it is easy to brute force 2^32. Alternatively you can do chained hashing similar to how GCM’s GHASH works but then is not a unique mapping, but that is not better the CTR mode encryption PRNG style, and likely slower. Why would you do this at all, if it worked? Because at allows you to stick to encrypting only the packet number that can stay outside AEAD and thus avoid buffer modification. But I don’t see how it can work.
> 
> Mikkel
> 
>>> 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?
>> 
>>> Would that help alleviate the buffering of the stream data? Because tag is always the last thing in the packet.
>> 
>>>>> On Sun, Mar 25, 2018 at 2:09 AM, Deval, Manasi <[email-masked]> wrote:
>>>>> On Sat, Mar 24, 2018 at 9:35 PM, Mikkel Fahnøe Jørgensen <[email-masked]> wrote:
>>>>>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 25 Mar 2018 12:52:00 -0400

SPARX will keep it the buffer clean and it is also reasonably fast at about
500 cycles per byte, but it is going to add significantly more latency than
than a full AES-NI block encryption.

Consider the following PN encryption scheme which is not very different
from current proposal, but which avoids touching any AEAD data:

Derive a key K_pn, encrypt the the last 16 octets of AEAD tag X_pn =
E(K_pn, tail(tag, 16)).
The C_pn = (PX XOR X_pn) truncated to len(PN).
Store C_pn as the encrypted packet number.

I don’t think there is any repeat nonce / XOR weakness in this, but even if
there are, the protected secret is not that critical.

The encrypted packet number is now only consuming between 1 and 4 octets
and can be decrypted in the exact same manner.

This will not work out of the box because AEAD includes the packet number
so we need to modify the buffer. However, this isn’t required so we can
move the packet number out of the AEAD. But this is not so easy because the
rest of the header needs to be included and we don’t want the packet number
to be first in the packet. Placing it last could actually be an option
since it is useless until we see the AEAD tag anyway. In particular, you
would have all the required data in a single cache line which matters. (If
want to key duplicates you can you use the first encrypted bytes in the
packet rather than the packet number).

This approach still has the down side of consuming a full AES block
encryption that cannot be parallelised so we at about 24ns on current Intel
cores. However, any other encryption scheme that does not depend on
guessing that the packet number is in a given range, is likely to be slower.

I still think this is not worthwhile compared to segmented packet numbers,
but if has to be, it might be workable.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 25 March 2018 at 18.10.04, Christian Huitema ([email-masked]) wrote:

If we are exploring research ideas, one possibility would be to use 64 bit
sequence numbers, and encrypt them using a modern 64 bit cipher like SPARX (
https://www.cryptolux.org/index.php/SPARX). We can exclude the PN bits from
the authenticated data, since the actual sequence number is part of the
AEAD nonce.  With that, 64 bit encryption of the PN and AEAD encryption of
the payload can proceed in parallel. Decryption requires first decrypting
the PN to initialize the AEAD nonce, but that can be done without double
buffering.

Of course, the cost of that is header overhead, since the PN always
occupies 64 bits. So we are trading some overhead for hardware
acceleration. And we have to have some faith in the 64 bit encryption
algorithm. (SPARX was suggested to me by Jean-Philippe Aumusson, the author
of IPCrypt.)

-- Christian Huitema

On Mar 25, 2018, at 8:48 AM, Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

Finding alternative nonces won’t fix this problem.. If you encrypted the
header completely separately from the body, you could do something, but
then you waste space on extra header tags.

Mikkel

-Ekr

>> [email-masked]>; Christian Huitema <huitema@huitema..net
>> <[email-masked]>>; IETF QUIC WG <[email-masked]>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 25 Mar 2018 12:57:19 -0400

Forgot:

The PN length needs to be known from clear text, e.g. varlen encoded with
the length bits in clear text, or fixed size, or trial decrypted based on
past experience.

On 25 March 2018 at 18.52.00, Mikkel Fahnøe Jørgensen ([email-masked])
wrote:

Kind Regards,
Mikkel Fahnøe Jørgensen

-- Christian Huitema

Mikkel

-Ekr

---

From: Ian Swett <[email-masked]>
Date: Sun, 25 Mar 2018 17:48:28 +0000

To answer Eric's original two questions
1) I really like PN encryption's properties, and the fact it doesn't
require moving to a PN space per path in QUIC v1(Christian's option #4).
2) I'm pretty sad about how difficult the current design is to offload.

Adding an extra nonce does not feel like the right solution, for all the
reasons Eric cited, and it adds a fair bit of byte overhead.

One note on ossification Subodh and I discussed last week.  The current PN
encryption is certainly possible to implement in hardware with some costly
and QUIC specific hardware.  But baking the entire format of QUIC into
hardware could cause it's own type of ossification.  Only implementing bulk
encryption in hardware allows a much wider variety of APIs and should allow
re-use of existing AES-GCM offload hardware with minimal changes.

I believe PN encryption will cause datacenter users of QUIC to create a
version of QUIC without PN encryption(at least that'd be my plan).  I don't
know if the WG sees this as a bug or a feature?

I'd really like an alternate way to transform the packet number that would
be sufficiently unlinkable, but not require a 2-pass solution.  AERO may
work, but I don't understand it well enough from a quick read of the draft
to understand it's properties.  In my opinion/use cases, it's ok if we
can't offload the PN encryption.  The issue comes that we can't do the PN
encryption in software until the bulk encryption is finished, so we can't
offload anything.

On Sun, Mar 25, 2018 at 12:57 PM Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

> SPARX will keep it the buffer clean and it is also reasonably fast at
> about 500 cycles per byte, but it is going to add significantly more
> latency than than a full AES-NI block encryption.
>
> I don’t think there is any repeat nonce / XOR weakness in this, but even
> if there are, the protected secret is not that critical.
>
> https://www.cryptolux.org/index.php/SPARX
> <https://www.cryptolux.org/index..php/SPARX>). We can exclude the PN bits
> from the authenticated data, since the actual sequence number is part of
> the AEAD nonce.  With that, 64 bit encryption of the PN and AEAD encryption
> of the payload can proceed in parallel. Decryption requires first
> decrypting the PN to initialize the AEAD nonce, but that can be done
> without double buffering.
>
> If this is what is meant by “tag as IV” it is problematic for what I
> assume is meant by double buffering, i.e. the need to modify the packet
> buffer decryption. This is because the packet number and what follows must
> be un-XORed before verification can take place.
>
>> 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?
>>
>
>>> *From:* Eric Rescorla [mailto:ekr@rtfm..com <[email-masked]>]
>>> https://tools.ietf.org/html/draft-mcgrew-aero-00#ref-MF07

---

From: Christian Huitema <[email-masked]>
Date: Sun, 25 Mar 2018 20:18:01 -0700

On 3/24/2018 9:25 AM, Eric Rescorla wrote:
> details, but roughly speaking, it's like an extension of AEAD which
> also takes the sequence number as an input on encryption and then
> returns it on decryption, so you don't need a separate sequence number
> or nonce. Obviously this is pretty much designed for our purpose, but
> it's a relatively new construction and so I don't know how much
> analysis there has been of its security. In addition, while it's based
> on AES-CTR, I don't know what the performance is like in hardware.

I am not so sure about that. The AERO construct relies on a "Wide
Pseudo-Random Permutation" (WPRP). To quote from the AERO draft, "A WPRP
has the property that each bit of its output is a pseudorandom function
of each bit of both of its inputs, for both encryption and decryption."
With that property, the sequence number can be appended to the plain
text; all bits of output will depend on it, in the same way that all
bits of the AEAD input depend on the nonce. But, to quote from the draft
again, "A WPRP is necessarily an offline algorithm", and "offline
algorithms cannot be implemented in a hardware pipeline, such as those
used in high-speed network encryption (for protocols such as 802.1AE)."

The AERO draft goes on explaining that the WPRP requirement might be
relaxed with a different construct,  "Online Pseudo-Random Permutation"
(OPRP), in which "the ith block of output depends only on the first i
blocks of input, for all values of i." But that construct is not
actually developed in the draft.

-- Christian Huitema

but that alternative construct is not fully explained.

-- Christian Huitema

---

From: "Deval, Manasi" <[email-masked]>
Date: Mon, 26 Mar 2018 06:10:43 +0000

The non-ideal solutions listed below provide a trade-off such that extra bytes in the header provide a simplified scheme for offload. I’m curious to understand if there is any other issue beyond the increase of header length.

Thanks,
Manasi

From: Eric Rescorla [mailto:[email-masked]]
Sent: Saturday, March 24, 2018 6:55 PM
To: Deval, Manasi <[email-masked]>
Cc: Mikkel Fahnøe Jørgensen <[email-masked]>; Kazuho Oku <[email-masked]>; Christian Huitema <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Hardware acceleration and packet number encryption

-Ekr

Thanks,
Manasi

-Ekr

Mikkel

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 26 Mar 2018 13:02:24 +0000

What percentage of QUIC clients and servers are likely to have this hardware offload, and under what timetable?  And are those claims true for *all* hardware acceleration?

I appreciate that this is really asking to guess and predict the future, *But* a hardware vendor is making the team inclined to give up privacy for a performance gain. That’s not the right trade-off for us to be making at this point in time.

-1

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 26 Mar 2018 15:46:34 +0200

I added some comments to PR related to my previously suggested changes to
the encryption scheme
https://github.com/quicwg/base-drafts/pull/1079

Mikkel

On 26 March 2018 at 15.02.30, Salz, Rich ([email-masked]) wrote:

What percentage of QUIC clients and servers are likely to have this
hardware offload, and under what timetable?  And are those claims true for *
*all** hardware acceleration?

I appreciate that this is really asking to guess and predict the future, *
*But** a hardware vendor is making the team inclined to give up privacy for
a performance gain. That’s not the right trade-off for us to be making at
this point in time.

-1

---

From: Ian Swett <[email-masked]>
Date: Mon, 26 Mar 2018 14:32:12 +0000

Good question Rich.

I'd estimate almost no clients would have this, unless a client is actually
another machine in a datacenter.

I can imagine 50% of servers may have this, but that's certainly an
estimate.  Today, based on talking to many organizations who operate
servers, I think this number is <10% on the public internet.  Datacenters
may be higher, I'm not sure.

I would much rather do #1079 than add extra bytes in the header to make
crypto offload easier.

Because the current PR uses the front of the encrypted payload as input to
the PN encryption, one could encrypt the front of the packet(ie: 2 AES-GCM
operations), then encrypt the packet number, then discard the front of the
payload and do everything with bulk offload or start encrypting after the
beginning of the packet.  This may cause an implementation to put padding
into the beginning of the packet if they want offload and have nothing
useful to send, but that seems better than forcing everyone to waste bytes
and add more unencrypted bytes to the header.

On Mon, Mar 26, 2018 at 9:46 AM Mikkel Fahnøe Jørgensen <[email-masked]>
wrote:

> *But** a hardware vendor is making the team inclined to give up privacy
> for a performance gain. That’s not the right trade-off for us to be making
> at this point in time.
>
>
>
> -1
>
>
>
>
>
>

---

From: "Swindells, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Mon, 26 Mar 2018 15:20:44 +0000

When you say ‘have this’ what exactly are you referring to dedicated hardware accelerator cards? Or were you counting processors with optimized CPU instructions?

Looking at https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_AMD_x86_architecture it seems to imply a large range of server, desktop and mobile chips all have a CPU instruction set available to do AES acceleration and other similar operations (other instruction sets are also available).

If we are considering the AES instructions then it looks like it is (or at least will be in the near future) a sizeable proportion of the public internet have it to be used.

I think it is useful for people who specialize in hardware to give expert guidance on the implication of design decisions, particularly as performance (or power efficiency) are important considerations for many people. There are three possible responses to that advice:

  1.  A different mechanism is found that gives better potential performance whilst also keeping the potential privacy benefits
  2.  The potential performance benefits are chosen with a risk that privacy guarantees may potentially be reduced
  3.  The potential privacy benefits are chosen with a risk of reduced performance compared to other protocols

What will influence the discussion is of course how big an impact is actually felt in each direction in the long run. For instance, it may turns out that regardless of how we encrypt the packet numbers there are still effective privacy breaching attacks in which case performance may have been the better thing to go for. Unfortunately in the short run people can only guess or estimate the factors – unless research is available showing this attacks already.

My personal view is that I’m not currently convinced that packet number encryption will actually bring a significant long lasting benefit compared to the costs it appears to have; and that in particular various timing and side channel attacks will allow correlation of sessions with a good degree of accuracy even without access to the packet numbers.

Of course the best result would be to have a solution which is response 1 – preserves both privacy and maintaining encryption acceleration.

Thomas

From: QUIC [mailto:[email-masked]] On Behalf Of Ian Swett
Sent: Monday, March 26, 2018 3:32 PM
To: Mikkel Fahnøe Jørgensen <[email-masked]>
Cc: Eric Rescorla <[email-masked]>; Salz, Rich <[email-masked]>; Christian Huitema <[email-masked]>; IETF QUIC WG <[email-masked]>; Deval, Manasi <[email-masked]>; Kazuho Oku <[email-masked]>
Subject: Re: Hardware acceleration and packet number encryption

Good question Rich.

I'd estimate almost no clients would have this, unless a client is actually another machine in a datacenter.

I can imagine 50% of servers may have this, but that's certainly an estimate.  Today, based on talking to many organizations who operate servers, I think this number is <10% on the public internet.  Datacenters may be higher, I'm not sure.

I would much rather do #1079 than add extra bytes in the header to make crypto offload easier.

Because the current PR uses the front of the encrypted payload as input to the PN encryption, one could encrypt the front of the packet(ie: 2 AES-GCM operations), then encrypt the packet number, then discard the front of the payload and do everything with bulk offload or start encrypting after the beginning of the packet.  This may cause an implementation to put padding into the beginning of the packet if they want offload and have nothing useful to send, but that seems better than forcing everyone to waste bytes and add more unencrypted bytes to the header.

On Mon, Mar 26, 2018 at 9:46 AM Mikkel Fahnøe Jørgensen <[email-masked]<mailto:mikkelfj@gmail..com>> wrote:
I added some comments to PR related to my previously suggested changes to the encryption scheme
https://github.com/quicwg/base-drafts/pull/1079

Mikkel

On 26 March 2018 at 15.02.30, Salz, Rich ([email-masked]<mailto:[email-masked]>) wrote:
What percentage of QUIC clients and servers are likely to have this hardware offload, and under what timetable?  And are those claims true for *all* hardware acceleration?

-1

---

From: "Swindells, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Mon, 26 Mar 2018 15:20:44 +0000

Thomas

Good question Rich.

Mikkel

-1

---

From: "Deval, Manasi" <[email-masked]>
Date: Mon, 26 Mar 2018 15:49:02 +0000

Even if the PN encryption is done in hardware, it does not automatically follow that the QUIC packet format is baked in hardware. The modern server side hardware that can deploy QUIC are quite flexible in interpreting the header formats.

There are three new ideas on this list - AES CTR, AERO and SPARX. It would take some time to evaluate the implementation and performance of these in both in software and as a hardware offload. I am on vacation this week and will pick this up when I return next week.

Thanks,
Manasi

From: Ian Swett [mailto:[email-masked]]
Sent: Sunday, March 25, 2018 10:48 AM
To: Mikkel Fahnøe Jørgensen <[email-masked]>
Cc: Christian Huitema <[email-masked]>; Subodh Iyengar <[email-masked]>; Eric Rescorla <[email-masked]>; IETF QUIC WG <[email-masked]>; Deval, Manasi <[email-masked]>; Kazuho Oku <[email-masked]>
Subject: Re: Hardware acceleration and packet number encryption

To answer Eric's original two questions
1) I really like PN encryption's properties, and the fact it doesn't require moving to a PN space per path in QUIC v1(Christian's option #4).
2) I'm pretty sad about how difficult the current design is to offload.

Adding an extra nonce does not feel like the right solution, for all the reasons Eric cited, and it adds a fair bit of byte overhead.

One note on ossification Subodh and I discussed last week.  The current PN encryption is certainly possible to implement in hardware with some costly and QUIC specific hardware.  But baking the entire format of QUIC into hardware could cause it's own type of ossification.  Only implementing bulk encryption in hardware allows a much wider variety of APIs and should allow re-use of existing AES-GCM offload hardware with minimal changes.

I believe PN encryption will cause datacenter users of QUIC to create a version of QUIC without PN encryption(at least that'd be my plan).  I don't know if the WG sees this as a bug or a feature?

I'd really like an alternate way to transform the packet number that would be sufficiently unlinkable, but not require a 2-pass solution.  AERO may work, but I don't understand it well enough from a quick read of the draft to understand it's properties.  In my opinion/use cases, it's ok if we can't offload the PN encryption.  The issue comes that we can't do the PN encryption in software until the bulk encryption is finished, so we can't offload anything.

On Sun, Mar 25, 2018 at 12:57 PM Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>> wrote:
Forgot:

The PN length needs to be known from clear text, e.g. varlen encoded with the length bits in clear text, or fixed size, or trial decrypted based on past experience.

On 25 March 2018 at 18.52.00, Mikkel Fahnøe Jørgensen ([email-masked]<mailto:[email-masked]>) wrote:
SPARX will keep it the buffer clean and it is also reasonably fast at about 500 cycles per byte, but it is going to add significantly more latency than than a full AES-NI block encryption.

Consider the following PN encryption scheme which is not very different from current proposal, but which avoids touching any AEAD data:

Derive a key K_pn, encrypt the the last 16 octets of AEAD tag X_pn = E(K_pn, tail(tag, 16)).
The C_pn = (PX XOR X_pn) truncated to len(PN).
Store C_pn as the encrypted packet number.

I don’t think there is any repeat nonce / XOR weakness in this, but even if there are, the protected secret is not that critical.

The encrypted packet number is now only consuming between 1 and 4 octets and can be decrypted in the exact same manner.

This will not work out of the box because AEAD includes the packet number so we need to modify the buffer. However, this isn’t required so we can move the packet number out of the AEAD. But this is not so easy because the rest of the header needs to be included and we don’t want the packet number to be first in the packet. Placing it last could actually be an option since it is useless until we see the AEAD tag anyway. In particular, you would have all the required data in a single cache line which matters. (If want to key duplicates you can you use the first encrypted bytes in the packet rather than the packet number).

This approach still has the down side of consuming a full AES block encryption that cannot be parallelised so we at about 24ns on current Intel cores. However, any other encryption scheme that does not depend on guessing that the packet number is in a given range, is likely to be slower.

I still think this is not worthwhile compared to segmented packet numbers, but if has to be, it might be workable.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 25 March 2018 at 18.10.04, Christian Huitema ([email-masked]<mailto:[email-masked]>) wrote:
If we are exploring research ideas, one possibility would be to use 64 bit sequence numbers, and encrypt them using a modern 64 bit cipher like SPARX (https://www.cryptolux.org/index.php/SPARX<https://www.cryptolux.org/index..php/SPARX>). We can exclude the PN bits from the authenticated data, since the actual sequence number is part of the AEAD nonce.  With that, 64 bit encryption of the PN and AEAD encryption of the payload can proceed in parallel. Decryption requires first decrypting the PN to initialize the AEAD nonce, but that can be done without double buffering.

-- Christian Huitema

On Mar 25, 2018, at 8:48 AM, Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>> wrote:
The tag used as IV in ECB mode for PN enceryption will use a full block size which is 16 octets. The proposal was encrypt the tag and XOR the result over that packet number and what follows.

Finding alternative nonces won’t fix this problem.. If you encrypted the header completely separately from the body, you could do something, but then you waste space on extra header tags.

Mikkel

On 25 March 2018 at 14.25.07, Eric Rescorla ([email-masked]<mailto:[email-masked]>) wrote:

On Sat, Mar 24, 2018 at 9:41 PM, Subodh Iyengar <[email-masked]<mailto:[email-masked]>> 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?

-Ekr

Subodh

-Ekr

Thanks,
Manasi

From: Eric Rescorla [mailto:ekr@rtfm..com<mailto:[email-masked]>]
Sent: Saturday, March 24, 2018 3:18 PM
To: Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>>
Cc: Kazuho Oku <[email-masked]<mailto:[email-masked]>>; Deval, Manasi <[email-masked]<mailto:[email-masked]>>; Christian Huitema <huitema@huitema..net<mailto:[email-masked]>>; IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Hardware acceleration and packet number encryption

-Ekr

Mikkel

---

From: Christian Huitema <[email-masked]>
Date: Mon, 26 Mar 2018 09:40:47 -0700

On 3/26/2018 8:20 AM, Swindells, Thomas (Nokia - GB/Cambridge) wrote:
>
> Looking at
> https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_AMD_x86_architectureit
> seems to imply a large range of server, desktop and mobile chips all
> have a CPU instruction set available to do AES acceleration and other
> similar operations (other instruction sets are also available).
>
> If we are considering the AES instructions then it looks like it is
> (or at least will be in the near future) a sizeable proportion of the
> public internet have it to be used.
>

Certainly, but that's not the current debate. PR #1079 is fully
compatible with use of the AES instructions. The issue of the debate is
that the mechanism in PR #1079 required double buffering, first encrypt
the payload, then use the result of the encryption to encrypt the PN.
This is not an issue in a software implementation that can readily
access all bytes of the packet from memory, but it may be an issue in
some hardware implementations that are designed to do just one pass over
the data.

-- Christian Huitema

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 29 Mar 2018 01:03:42 +0100

A few quick thoughts as I catch up on this thread.

I spent some time last week working through a design using multiple PN
spaces, and it is quite doable. I suspect we'll head towards multiple PN
spaces as we consider multipath in the future. That said, there is
complexity (as Christian notes). This complexity may be warranted when
doing multipath in v2 or later, but I'm not convinced that this is
necessary as a design primitive for QUICv1.

We may want to creatively use the PN bits in v2, say to encode a path ID
and a PN, for multipath. We want to retain flexibility in these bits going
into v2. We've used encryption to ensure that we don't lose flexibility
elsewhere in the header, and it follows that we should use PNE to retain
flexibility in these bits as well. (Simplicity of design is the other value
in using PNE, since handling migration linkability is non-trivial without
it.)

This leaves the question of HW acceleration being at loggerheads with the
design in PR #1079. First, I expect that the primary benefit of
acceleration will be in DC environments. Yes, there are some gains to be
had in serving the public Internet as well, but I'm unconvinced that this
is the driving use case for hardware acceleration. I understand that others
may disagree with me here.

AFAIK, QUIC has not been used in DC environments yet. I expect there are
other things in the protocol that we'd want to change as we gain experience
deploying QUIC in DCs. Spinning up a new version to try QUIC within DCs is
not only appropriate, I would recommend it. This allows for rapid
iterations internally, and the experience can drive subsequent changes to
QUIC. It's what *I* would do if I was to deploy QUIC inside a DC.

So, in short, I think we should go ahead with PR# 1079. This ensures that
future versions are guaranteed the flexibility to change the PN bits for
better support of HW acceleration or multipath or what-have-you.

- jana

On Mar 26, 2018 9:41 AM, "Christian Huitema" <[email-masked]> wrote:

Looking at https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_
AMD_x86_architecture it seems to imply a large range of server, desktop and
mobile chips all have a CPU instruction set available to do AES
acceleration and other similar operations (other instruction sets are also
available).

If we are considering the AES instructions then it looks like it is (or at
least will be in the near future) a sizeable proportion of the public
internet have it to be used.

Certainly, but that's not the current debate. PR #1079 is fully compatible
with use of the AES instructions. The issue of the debate is that the
mechanism in PR #1079 required double buffering, first encrypt the payload,
then use the result of the encryption to encrypt the PN. This is not an
issue in a software implementation that can readily access all bytes of the
packet from memory, but it may be an issue in some hardware implementations
that are designed to do just one pass over the data.

-- Christian Huitema

---

From: Ian Swett <[email-masked]>
Date: Thu, 29 Mar 2018 00:39:20 +0000

Thanks for the nice summary Jana.

As much as I'd love to have easier crypto HW acceleration, I've ended up
arriving at the same conclusion.  I don't want to bite off the work to do
proper multipath in QUIC v1, which I think is the only other reasonable
option of those Christian outlined.

If someone comes up with a way to transform packet number to make it
non-linkable, but doesn't have the downside of making hardware offload
difficult, then I'm open to it.  But we've been talking about this for 2
months without any notable improvements over Martin's PR.

Given we never talk about any issue only once in QUIC, I'm sure this will
come up again, but for the time being I think #1079 is the best option we
have.

On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar <[email-masked]> wrote:

> https://en.wikipedia.org/wiki/AES_instruction_set#Intel_and_AMD_x86_architecture
> it seems to imply a large range of server, desktop and mobile chips all

---

From: Watson Ladd <[email-masked]>
Date: Wed, 28 Mar 2018 18:54:15 -0700

> come up again, but for the time being I think #1079 is the best option we

I am not so sure this is right. Some proposals I've seen upthread:
- Use a 64 bit blockcipher to encrypt the sequence number
- Various online modes that may or may not be a good idea

And another idea I just had:
-Put the encrypted packet number last in the buffer so it gets
outputed at the right time for transmitting hardware, and then have
the receiving hardware copy the bytes to the front before passing it
through the decryptor.

Admittedly I don't understand the constraints on hardware that might
be a problem for these approaches, but I don't think we are quite
licked yet.

Sincerely,
Watson
>> complexity (as Christian notes). This complexity may be warranted when doing
>> multipath in v2 or later, but I'm not convinced that this is necessary as a
>> design primitive for QUICv1.
>>
>> design in PR #1079. First, I expect that the primary benefit of acceleration
>> will be in DC environments. Yes, there are some gains to be had in serving
>> the public Internet as well, but I'm unconvinced that this is the driving
>> use case for hardware acceleration. I understand that others may disagree
>> with me here.
>>
>> not only appropriate, I would recommend it. This allows for rapid iterations
>> internally, and the experience can drive subsequent changes to QUIC. It's
>> what *I* would do if I was to deploy QUIC inside a DC.
>>
>> it seems to imply a large range of server, desktop and mobile chips all have
>> a CPU instruction set available to do AES acceleration and other similar
>> operations (other instruction sets are also available).
>>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 28 Mar 2018 18:54:15 -0700

Sincerely,
Watson

---

From: Praveen Balasubramanian <[email-masked]>
Date: Thu, 29 Mar 2018 02:46:36 +0000

Sorry for late response just catching up with this thread.

Re. applicability of hardware offload
This is much broader than the datacenter scenario. We rely on TCP offloads today for performance of all web services even on the front end. TCP offloads are present pretty much on every server and VM and on by default. We cannot afford to make the tradeoff of 2x or more increase in CPU cost for driving the same workload over QUIC as compared to TCP. If QUIC is being looked at as a general purpose transport and a replacement of TCP, then hardware offload is absolutely an important requirement. We already have scenarios in progress that are non-HTTP. Over time the TCP offloads have also been supported on client systems primarily on Ethernet, but we have seen recent adoption in Wifi NICs and mobile broadband as well. The CPU savings are large even at smaller data rates. I'd be happy to publish the numbers we have around offloads like LSO and LRO. 

Re. multiple PN spaces
I am not understanding why this has high implementation cost so please explain more. For one, this seems to be needed primarily for connection migration which to me looks like an optional feature of QUIC v1 (not sure if this is stated as such in the draft but it should be). And implementations that choose to build connection migration support might as well do the right design so they are ready for multi-path. 

My preference order for different proposed solutions:
1. Multiple PN spaces without PNE. 
2. Negotiate PNE and allow implementations to skip it if they do not support connection migration or multi-path. All datacenter scenarios will qualify, apps that do not want to use multiple paths will qualify and all systems that do not have multiple NICs (or paths) will qualify. This will allow us to make incremental progress and work on better hardware support over time. Option 2 holds irrespective of single or multiple PN spaces.
3. Any alternative form of PNE that doesn’t cause issues for offloads. Still not ideal CPU cost wise (for when we cannot offload) but seems to have other benefits so we can live with it.

Now I understand that leaving PN in the clear may cause ossification issue but that seems solvable by greasing both the starting PN and subsequently not always incrementing by 1 in the clear.

Thanks

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Watson Ladd
Sent: Wednesday, March 28, 2018 6:54 PM
To: Ian Swett <[email-masked]>
Cc: Jana Iyengar <[email-masked]>; IETF QUIC WG <[email-masked]>; huitema <[email-masked]>
Subject: Re: Hardware acceleration and packet number encryption

On Wed, Mar 28, 2018 at 5:39 PM, Ian Swett <ianswett=[email-masked]> wrote:
> As much as I'd love to have easier crypto HW acceleration, I've ended 
> up arriving at the same conclusion.  I don't want to bite off the work 
> to do proper multipath in QUIC v1, which I think is the only other 
> reasonable option of those Christian outlined.
>
> difficult, then I'm open to it.  But we've been talking about this for 
> 2 months without any notable improvements over Martin's PR.
>
> Given we never talk about any issue only once in QUIC, I'm sure this 
> will come up again, but for the time being I think #1079 is the best 
> option we have.

And another idea I just had:
-Put the encrypted packet number last in the buffer so it gets outputed at the right time for transmitting hardware, and then have the receiving hardware copy the bytes to the front before passing it through the decryptor.

Admittedly I don't understand the constraints on hardware that might be a problem for these approaches, but I don't think we are quite licked yet.

Sincerely,
Watson
>> I spent some time last week working through a design using multiple 
>> PN spaces, and it is quite doable. I suspect we'll head towards 
>> multiple PN spaces as we consider multipath in the future. That said, 
>> there is complexity (as Christian notes). This complexity may be 
>> warranted when doing multipath in v2 or later, but I'm not convinced 
>> that this is necessary as a design primitive for QUICv1.
>>
>> We may want to creatively use the PN bits in v2, say to encode a path 
>> ID and a PN, for multipath. We want to retain flexibility in these 
>> bits going into v2. We've used encryption to ensure that we don't 
>> lose flexibility elsewhere in the header, and it follows that we 
>> should use PNE to retain flexibility in these bits as well. 
>> (Simplicity of design is the other value in using PNE, since handling 
>> migration linkability is non-trivial without
>> it.)
>>
>> This leaves the question of HW acceleration being at loggerheads with 
>> the design in PR #1079. First, I expect that the primary benefit of 
>> acceleration will be in DC environments. Yes, there are some gains to 
>> be had in serving the public Internet as well, but I'm unconvinced 
>> that this is the driving use case for hardware acceleration. I 
>> understand that others may disagree with me here.
>>
>> AFAIK, QUIC has not been used in DC environments yet. I expect there 
>> are other things in the protocol that we'd want to change as we gain 
>> experience deploying QUIC in DCs. Spinning up a new version to try 
>> QUIC within DCs is not only appropriate, I would recommend it. This 
>> allows for rapid iterations internally, and the experience can drive 
>> subsequent changes to QUIC. It's what *I* would do if I was to deploy QUIC inside a DC.
>>
>> So, in short, I think we should go ahead with PR# 1079. This ensures 
>> that future versions are guaranteed the flexibility to change the PN 
>> bits for better support of HW acceleration or multipath or what-have-you.
>>
>> - jana
>>
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fen.w
>> ikipedia.org%2Fwiki%2FAES_instruction_set%23Intel_and_AMD_x86_archite
>> cture&data=02%7C01%7Cpravb%40microsoft.com%7C8124554015264408874708d5
>> 95180268%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636578852732108
>> 907&sdata=4kf2m4KYai6Gd6j4Vc1nFOpddVaBKP%2FRXRDcBF57JRQ%3D&reserved=0
>> it seems to imply a large range of server, desktop and mobile chips 
>> all have a CPU instruction set available to do AES acceleration and 
>> other similar operations (other instruction sets are also available).
>>
>> compatible with use of the AES instructions. The issue of the debate 
>> is that the mechanism in PR #1079 required double buffering, first 
>> encrypt the payload, then use the result of the encryption to encrypt 
>> the PN. This is not an issue in a software implementation that can 
>> readily access all bytes of the packet from memory, but it may be an 
>> issue in some hardware implementations that are designed to do just one pass over the data.
>>
>>
>> -- Christian Huitema
>>
>>
>>
>

---

From: Praveen Balasubramanian <[email-masked]>
Date: Sat, 31 Mar 2018 16:21:30 +0000

PNE is actually PNT (packet number transform) as I recall Jana had pointed out in the early discussions. Encryption is just one possible transform to apply to the actual PN before putting it in the clear portion of the header. There are other possible transforms like increment, XOR, and no-op. Preventing linkability seems to require encryption but I am not convinced that it actually provides unlikability or is worth the extra computation  cost per packet. Can someone please clarify how it prevents a simple attack like looking at timing of failovers to link IP addresses? Preventing ossification requires a transform that does some form of greasing. If we go down the path of negotiation for the transform, the client initial PN will need to be random and treated specially just like the CID and there are likely some other gotchas I haven’t thought of. 

Thanks

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Praveen Balasubramanian
Sent: Wednesday, March 28, 2018 7:47 PM
To: Watson Ladd <[email-masked]>; Ian Swett <[email-masked]>
Cc: Jana Iyengar <[email-masked]>; IETF QUIC WG <[email-masked]>; huitema <[email-masked]>
Subject: RE: Hardware acceleration and packet number encryption

Re. multiple PN spaces

Thanks

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Watson Ladd
Sent: Wednesday, March 28, 2018 6:54 PM
To: Ian Swett <[email-masked]>
Cc: Jana Iyengar <[email-masked]>; IETF QUIC WG <[email-masked]>; huitema <[email-masked]>
Subject: Re: Hardware acceleration and packet number encryption

Sincerely,
Watson

---

From: Praveen Balasubramanian <[email-masked]>
Date: Sat, 31 Mar 2018 16:21:30 +0000

Thanks

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Praveen Balasubramanian
Sent: Wednesday, March 28, 2018 7:47 PM
To: Watson Ladd <[email-masked]>; Ian Swett <[email-masked]>
Cc: Jana Iyengar <[email-masked]>; IETF QUIC WG <[email-masked]>; huitema <[email-masked]>
Subject: RE: Hardware acceleration and packet number encryption

Re. multiple PN spaces

Thanks

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Watson Ladd
Sent: Wednesday, March 28, 2018 6:54 PM
To: Ian Swett <[email-masked]>
Cc: Jana Iyengar <[email-masked]>; IETF QUIC WG <[email-masked]>; huitema <[email-masked]>
Subject: Re: Hardware acceleration and packet number encryption

Sincerely,
Watson

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sat, 31 Mar 2018 10:56:34 -0700

I can live with packet number encryption in v1 if it opens up for
unencrypted multipath multi PN spaces in v2. This in turn, we solve the
issue with single pass hardware for v2 - since there is then no encryption.

However, I strongly suggest that it is done in a way that does not require
buffer modification for encryption. That means the the packet number cannot
be part of the AEAD data. It is also not difficult to avoid - see my
comments added to PR 1079.

As to 64-bit encryption - I seriously doubt this is worthwhile -
non-standard, takes up space, dubious security given enough power, and
again, it is not necessary because you can encrypt packet numbers down to a
single byte if you keep the PN out fo the AEAD data. Please provide a
counter argument if you think that this is not correct:
https://github.com/quicwg/base-drafts/pull/1079#issuecomment-376165638

The only issue I see is whether the PN should be placed first or last - and
if hardware acceleration is not the target for v1, it should be placed last..

- and again, I think it is futile to encrypt packet numbers for linkability
protection, but as I said, if it opens up for V2 without it, please by all
means, let's get this over with. Just don’t require in-place buffer updates
or buffer copies before verification and decryption. It is not necessary.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 31 March 2018 at 18.21.48, Praveen Balasubramanian (
pravb=[email-masked]) wrote:

PNE is actually PNT (packet number transform) as I recall Jana had pointed
out in the early discussions. Encryption is just one possible transform to
apply to the actual PN before putting it in the clear portion of the
header. There are other possible transforms like increment, XOR, and no-op.
Preventing linkability seems to require encryption but I am not convinced
that it actually provides unlikability or is worth the extra computation
cost per packet. Can someone please clarify how it prevents a simple attack
like looking at timing of failovers to link IP addresses? Preventing
ossification requires a transform that does some form of greasing. If we go
down the path of negotiation for the transform, the client initial PN will
need to be random and treated specially just like the CID and there are
likely some other gotchas I haven’t thought of.

Thanks

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Praveen
Balasubramanian
Sent: Wednesday, March 28, 2018 7:47 PM
To: Watson Ladd <[email-masked]>; Ian Swett <[email-masked]>
Cc: Jana Iyengar <[email-masked]>; IETF QUIC WG <[email-masked]>;
huitema <[email-masked]>
Subject: RE: Hardware acceleration and packet number encryption

Re. applicability of hardware offload
This is much broader than the datacenter scenario. We rely on TCP offloads
today for performance of all web services even on the front end. TCP
offloads are present pretty much on every server and VM and on by default.
We cannot afford to make the tradeoff of 2x or more increase in CPU cost
for driving the same workload over QUIC as compared to TCP. If QUIC is
being looked at as a general purpose transport and a replacement of TCP,
then hardware offload is absolutely an important requirement. We already
have scenarios in progress that are non-HTTP. Over time the TCP offloads
have also been supported on client systems primarily on Ethernet, but we
have seen recent adoption in Wifi NICs and mobile broadband as well. The
CPU savings are large even at smaller data rates. I'd be happy to publish
the numbers we have around offloads like LSO and LRO.

Re. multiple PN spaces
I am not understanding why this has high implementation cost so please
explain more. For one, this seems to be needed primarily for connection
migration which to me looks like an optional feature of QUIC v1 (not sure
if this is stated as such in the draft but it should be). And
implementations that choose to build connection migration support might as
well do the right design so they are ready for multi-path.

My preference order for different proposed solutions:
1. Multiple PN spaces without PNE.
2. Negotiate PNE and allow implementations to skip it if they do not
support connection migration or multi-path. All datacenter scenarios will
qualify, apps that do not want to use multiple paths will qualify and all
systems that do not have multiple NICs (or paths) will qualify. This will
allow us to make incremental progress and work on better hardware support
over time. Option 2 holds irrespective of single or multiple PN spaces.
3. Any alternative form of PNE that doesn’t cause issues for offloads.
Still not ideal CPU cost wise (for when we cannot offload) but seems to
have other benefits so we can live with it.

Now I understand that leaving PN in the clear may cause ossification issue
but that seems solvable by greasing both the starting PN and subsequently
not always incrementing by 1 in the clear.

Thanks

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Watson Ladd
Sent: Wednesday, March 28, 2018 6:54 PM
To: Ian Swett <[email-masked]>
Cc: Jana Iyengar <[email-masked]>; IETF QUIC WG <[email-masked]>;
huitema <[email-masked]>
Subject: Re: Hardware acceleration and packet number encryption

And another idea I just had:
-Put the encrypted packet number last in the buffer so it gets outputed at
the right time for transmitting hardware, and then have the receiving
hardware copy the bytes to the front before passing it through the
decryptor.

Admittedly I don't understand the constraints on hardware that might be a
problem for these approaches, but I don't think we are quite licked yet.

Sincerely,
Watson

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sat, 31 Mar 2018 10:56:34 -0700

The only issue I see is whether the PN should be placed first or last - and
if hardware acceleration is not the target for v1, it should be placed last.

Kind Regards,
Mikkel Fahnøe Jørgensen

Thanks

-----Original Message-----

Re. multiple PN spaces

Thanks

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Watson Ladd
Sent: Wednesday, March 28, 2018 6:54 PM
To: Ian Swett <[email-masked]>
Cc: Jana Iyengar <[email-masked]>; IETF QUIC WG <[email-masked]>;

Sincerely,
Watson

---

From: Praveen Balasubramanian <[email-masked]>
Date: Sat, 31 Mar 2018 18:17:32 +0000

>> and if hardware acceleration is not the target for v1
I don’t know where this is coming from. It is for sure a target for V1 and discussions are already underway about this. Hardware refresh cycles take many years and there is next gen hardware being designed right now. Not having offloads will delay server adoption. Not every web service can make the trade off to throw a lot more compute to get better latency performance.

PN size and location needs to be part of invariants. How the field is transformed and encoded in the clear is an end-to-end function and can change between versions. I’d be happy if we simply do greasing to prevent ossification in V1. Optionally add a preliminary design for implementations doing connection migration and allow those cases to do either of: 1. PNE if it is deemed that the CPU trade off to get “unlinkability” is worth it, or 2. multiple PN spaces.

PS: In my opinion connection migration and multi-path should be deferred to V2 since I am of the view that connection migration is just a special case of multi-path and I’d rather do one design the right way for it than some throwaway intermediate work. Also both of these require load balancer updates which means you cannot host your web server in public clouds and expect these features to work any time soon.

From: QUIC [mailto:[email-masked]] On Behalf Of Mikkel Fahnøe Jørgensen
Sent: Saturday, March 31, 2018 10:57 AM
To: Praveen Balasubramanian <[email-masked]>; Watson Ladd <[email-masked]>; Ian Swett <[email-masked]>
Cc: Jana Iyengar <[email-masked]>; IETF QUIC WG <[email-masked]>; huitema <[email-masked]>
Subject: RE: Hardware acceleration and packet number encryption

I can live with packet number encryption in v1 if it opens up for unencrypted multipath multi PN spaces in v2. This in turn, we solve the issue with single pass hardware for v2 - since there is then no encryption.

However, I strongly suggest that it is done in a way that does not require buffer modification for encryption. That means the the packet number cannot be part of the AEAD data. It is also not difficult to avoid - see my comments added to PR 1079.

As to 64-bit encryption - I seriously doubt this is worthwhile - non-standard, takes up space, dubious security given enough power, and again, it is not necessary because you can encrypt packet numbers down to a single byte if you keep the PN out fo the AEAD data. Please provide a counter argument if you think that this is not correct:
https://github.com/quicwg/base-drafts/pull/1079#issuecomment-376165638<https://github...com/quicwg/base-drafts/pull/1079#issuecomment-376165638>

The only issue I see is whether the PN should be placed first or last - and if hardware acceleration is not the target for v1, it should be placed last.

- and again, I think it is futile to encrypt packet numbers for linkability protection, but as I said, if it opens up for V2 without it, please by all means, let's get this over with. Just don’t require in-place buffer updates or buffer copies before verification and decryption. It is not necessary.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 31 March 2018 at 18.21.48, Praveen Balasubramanian (pravb=[email-masked]<mailto:pravb=[email-masked]>) wrote:
PNE is actually PNT (packet number transform) as I recall Jana had pointed out in the early discussions. Encryption is just one possible transform to apply to the actual PN before putting it in the clear portion of the header. There are other possible transforms like increment, XOR, and no-op. Preventing linkability seems to require encryption but I am not convinced that it actually provides unlikability or is worth the extra computation cost per packet. Can someone please clarify how it prevents a simple attack like looking at timing of failovers to link IP addresses? Preventing ossification requires a transform that does some form of greasing. If we go down the path of negotiation for the transform, the client initial PN will need to be random and treated specially just like the CID and there are likely some other gotchas I haven’t thought of.

Thanks

-----Original Message-----
From: QUIC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Praveen Balasubramanian
Sent: Wednesday, March 28, 2018 7:47 PM
To: Watson Ladd <[email-masked]<mailto:[email-masked]>>; Ian Swett <[email-masked]<mailto:[email-masked]>>
Cc: Jana Iyengar <[email-masked]<mailto:[email-masked]>>; IETF QUIC WG <quic@ietf...org<mailto:[email-masked]>>; huitema <[email-masked]<mailto:[email-masked]>>
Subject: RE: Hardware acceleration and packet number encryption

Re. multiple PN spaces

Thanks

-----Original Message-----
From: QUIC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Watson Ladd
Sent: Wednesday, March 28, 2018 6:54 PM
To: Ian Swett <[email-masked]<mailto:[email-masked]>>
Cc: Jana Iyengar <[email-masked]<mailto:[email-masked]>>; IETF QUIC WG <quic@ietf...org<mailto:[email-masked]>>; huitema <[email-masked]<mailto:[email-masked]>>
Subject: Re: Hardware acceleration and packet number encryption

And another idea I just had:
-Put the encrypted packet number last in the buffer so it gets outputed at the right time for transmitting hardware, and then have the receiving hardware copy the bytes to the front before passing it through the decryptor...

Sincerely,
Watson
>
>
>
> On Wed, Mar 28, 2018 at 8:03 PM Jana Iyengar <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> On Mar 26, 2018 9:41 AM, "Christian Huitema" <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>
>> ikipedia.org<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fikipedia.org&data=02%7C01%7Cpravb%40microsoft.com%7Cf1923e470d2648a96ef208d59730c510%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636581158087189220&sdata=75BFKpzlad%2FwKoGXYxh4ilHQfICR4a6UdZNeGzcnf04%3D&reserved=0>%2Fwiki%2FAES_instruction_set%23Intel_and_AMD_x86_archite
>> cture&data=02%7C01%7Cpravb%40microsoft.com<http://40microsoft...com>%7C8124554015264408874708d5