Re: Hardware acceleration and packet number encryption

[Ian Swett <[e-mail]>]

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]>
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]) 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
>
>
>
>
>
>