RE: Hardware acceleration and packet number encryption

["Swindells, Thomas (Nokia - GB/Cambridge)" <[e-mail]>]

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:[e-mail]] On Behalf Of Ian Swett
Sent: Monday, March 26, 2018 3:32 PM
To: Mikkel Fahnøe Jørgensen <[e-mail]>
Cc: Eric Rescorla <[e-mail]>; Salz, Rich <[e-mail]>; Christian Huitema <[e-mail]>; IETF QUIC WG <[e-mail]>; Deval, Manasi <[e-mail]>; Kazuho Oku <[e-mail]>
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 <[e-mail]<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 ([e-mail]<mailto:[e-mail]>) 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