Hi,
This is my first e-mail to ietf.org . Bear over with me if the syntax is
not correct. I'm working as a kernel developer for the FreeBSD project
since very long and I'm directly involved with 100GBit/s network adapter
drivers and AES-GCM TLS (v1.2 and v1.3) hardware offload directly on
various network adapters (Chelsio and Mellanox(Nvidia mostly), both
receive and transmit direction. Typically done using TCP/IP as a bearer.
During production there is a recurring problem to compute the
authentication tags, that you technically need to feed all the TLS
record data prior to the hash tag, in order for the hash tag to be
correctly computed. This is because the socket buffer in the network
stack contains plaintext data, and the network card itself is
responsible for XOR-ing the AES-CTR pattern and then filling in the
correct authentication tag.
The AES-CTR is position dependent and can easily be rewinded or
forwarded by the byte offset in the TLS record, without having to re-DMA
any plaintext data over the PCI bus. However the authentication tag is
different.
As a proposal in general, entertainment content providers, do not
require the same level of confidence, that the data really comes from
the server as the security certificate indicates, which other content
providers like banks require. Actually the purpose of TLS for video
streaming is to prevent copying of video data, and also prevent
eavesdropping on users, like figuring out what videos they are watching,
and this need is entirely fulfilled by the AES-CTR mechanism. The
additional authentication tag mechanism, then just becomes an additional
burden for the server and also client, which really serves no purpose.
The proposal is to allocate a new "crypto codec number", forgive me if
my terms are not accurate for IETF, mirroring the existing AES-GCM-XXX
variants (128-bits / 192-bits / 256-bits), only that the hash tag area
may be filled with random data or used for debugging purposes, and is
completely ignored. Otherwise the protocols are identical.
This new algorithm will then be provided by the TLS / HTTPS server and
negotiated as usual using OpenSSL and used when both parties agrees.
The purpose of this proposal is to separate encryption for entertainment
purposes and for other non-entertainment purposes in an effort to
simplify the server side for large entertainment services typically
serving in multiples of 100GBit/s per single server. Where
non-entertainment services are typically less than 10GBit/s for a much
larger consumer volume, and can easily afford stronger authentication
algorithms, usually all done in software anyway.
Comments are welcome!
--HPS
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
