On Fri, Mar 24, 2023 at 2:09 AM Hans Petter Selasky <h...@selasky.org> 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? Sincerely, Watson Ladd -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
