Hi, The hardware offload Hans is referring to is for AES-GCM, and the integrity protection is the Galois MAC; SHA has nothing to do with it.
As it happens, my ANRP talk at the IRTF open meeting today (13:00) will explain how TLS offload in Mellanox NICs works, and hopefully it will clarify what's the problem with retransmissions, and why GMAC makes things harder to offload. If I understand correctly, Hans is proposing an AES-CTR ciphersuite with no integrity protection, but with the same TLS record format as AES-GCM records; the ICV can be random or zero filled. I don't know if AES-CTR is really useful, even in the CDN scenario, can someone comment on that? Best, Boris On Mon, Mar 27, 2023 at 7:00 AM Eric Rescorla <[email protected]> wrote: > Hans Petter, > > Before I address your technical points, I would observe that your > tone here isn't ideal for getting people excited about your ideas. > If you think there's something that people don't understand, then > by all means explain it, but telling people that they have a "total lack > of kernel-side insight" or that their "technology and ideas will be totally > left behind" doesn't really foster good will. > > > On Sat, Mar 25, 2023 at 12:41 AM Hans Petter Selasky <[email protected]> > wrote: > >> On 3/24/23 23:59, Watson Ladd wrote: >> > On Fri, Mar 24, 2023 at 2:09 AM Hans Petter Selasky <[email protected]> >> wrote: >> > <snip> >> >> OK >> >> >> >> I see where you guys are falling off. >> >> >> >> Professionals already encrypt the video files served using >> >> (confidentiality, integrity and authenticity). >> >> >> >> These files are also served using HTTP, unencrypted, but then people >> can >> >> easily compare the contents to figure out what is being watched, even >> if >> >> encrypted. >> >> >> >> The transport layer TCP/IP/TLS does not need the authenticity part in >> >> this case, because the files served are already fully encrypted, if >> that >> >> makes sense. >> > >> > The file is not what is transported over TLS connection. The HTTP >> > response is transported. That response includes things like headers >> > whose manipulation could have negative effects on security: e.g. >> > setting cookies. >> > >> > There's also a fundamental architectural issue: the HTTP server does >> > not know what file will be requested when negotiating the TLS >> > ciphersuite, and the TLS connection is used across multiple HTTP >> > requests. That makes accepting a different ciphersuite for some >> > requests extremely difficult to actually implement. >> > >> > Does the underlying encryption ensure authenticity? >> > >> > Lastly I'm not sure I understand what the performance issue is with >> > the offloading. I think what you're saying is you need more memory to >> > track the encrypted and authenticated segments on retransmission than >> > just knowing the offsets, but I think that would be a problem with any >> > sort of TLS record packing that has different boundaries from the TCP >> > segmentation. If you line them up, then the MAC tag isn't any more >> > difficult. It also isn't the case that AES-GCM can ignore the >> > segmentation even without the MAC: the nonce is xored with the >> > write_iv, and then the nonce is combined with a counter starting at 1 >> > that occupies the low 32 bits to get the keystream. >> > >> > Are you proposing just using AES-CTR ignoring the record segmentation >> entirely? >> >> Hi Watson Ladd, >> >> I had a longer conversation on Whatsapp with another guy from the IETF >> list. >> >> I see there is some knowledge gap between you guys sitting in the IETF >> and me in the implementation department sort of. >> > >> There are basically three ways to do TLS encryption: >> >> 1) OpenSSL (or the alike in user-space) >> 2) AES CPU instructions in the kernel (all done in kernel space) >> 3) The network card does AES encryption and decryption >> >> In case 1) and 2) there is no problem. >> >> In case 3) there is also no problem, until you have a packet loss and >> retransmission. The NIC cannot remember previously computed SHA-256 and >> AES-CTR data, and so if you need to retransmit only the SHA-256 hash >> data, then all of the TLS record, usually up to 16 kilobytes, needs to >> be "dumped" (not transmitted) via the crypto engine in the NIC, to >> re-compute the SHA-256 hash data. >> > > Several points here: > 1. Can you explain where SHA-256 comes in here, as it's not used with > AES-GCM? I'm not following the problematic scenario. > > 2. I understand that you say that there is a problem with packet loss and > retransmission, but on correctly functioning networks, packet loss rates > should be quite low (<5%), in which case the overhead of just treating > the retransmission as if it were a fresh send. I agree that it's not ideal, > but won't the overhead just be the same as if you were sending a few > percent more data. > > 3. Being able to retransmit pre-encrypted TLS records is a feature of > TLS over TCP, but not of QUIC, where retransmissions entail a fresh > encryption. As more traffic moves to H3, especially for high-speed > applications, it seems like any optimization we do here would be > increasingly > less useful. > > -Ekr > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
