On 3/24/23 23:59, Watson Ladd wrote:
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?
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.
One solution is that IETF allows that the SHA-256 is computed on the
plaintext data and not the encrypted data. Then the SHA-256 could be
done once by software and stored in the so-called socket-buffer, and
then the NIC will do the AES-CTR live on transmit.
From what I see there is a total lack of kernel-side insight in the
IETF organisation. You guys governing up there seem to use locked-down
OS'es like MAC and Windows, and so never consider the problems and
solutions for optimizing crypto!
There has been so much going on recently regarding TSO and LRO in
software in the kernel side, especially in FreeBSD, that if you don't
follow up on that, your technology and ideas will be totally left behind
in a few years time!
Best regards,
HP Selasky, Grimstad, Norway
Sincerely,
Watson Ladd
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
