Re: [TLS] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes
Hi, On 3/28/23 00:39, Hal Murray wrote: h...@selasky.org said: A typical video stream of 4 MBit/s may produce on average 333 packets per second, and I ask a simple question if it is really needed to authenticate all of those packets while the user sits in a chair and eats popcorn? Are you sure there is a user eating popcorn? The majority - yes. Are there any 0-day exploits in your video system? That's a reminder to not use over complicated and secret sauce video codecs. Probably there is a 0-day exploit in the .mp4 codec already, implanted by secret services. Who knows. Nice to get rid of it! Is that middle box doing the right thing? If someone tampers internet in my town, the half a mile it goes down to the bank, I'm pretty sure I'll figure it out myself. But you know how ISP's like to do it, they send the traffic hundreds of miles to the nearest data/recording center, and then sends it back again. Encryption will never solve that problem, internet traffic goes way longer than it should. Infact governments require access to crypto keys so they can decrypt all traffic anyway - so what are you saying about middle boxes doing again and encryption can do something about it? Nah, I don't think so. The main problem I see with your proposal is that it adds complexity. Everybody using TLS will now have to consider what happens if your option gets enabled and/or how to make sure that it doesn't get enabled. Security is complicated. Making it more complicated is a step in the wrong direction. Yes, that's why I want a central change in this area, and not something custom, to avoid a big fight about the next httpX protocol. Does your popcorn eating user need TLS as all? That's a good question. People eating popcorn while watching movies on the TV probably also knows how their internet works - so I guess the answer is no :-) --HPS ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes
On 3/26/23 23:59, Eric Rescorla 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. Hi Eric, Who is your leader? I was aware before posting this topic, that it might be a bit controversial. The reason I'm volunteering for this change, is simply because I think making yet another port-number or protocol, is not where I want to go, neither personally or professionally. In my mind, the AES-CTR should just use the TCP sequence number for offset, and then every now and then update the window so that you get a 64-bit sequence number. As simple as that. As Boris mentioned, the problem about the existing TLS protocol, with regards to hardware offload, appears when you get packet loss. When the received TCP packet stream is not contiguous. I have an impression that a lot of effort has gone into TLS v1.3 and I would like to ask a honest question, if hardware offloads, like done directly on a passive NIC, has ever been considered as parts of the plans and way forward? From my past experience working on various USB controllers, one thing you learn, is that to provide the physical memory pointer to the data you want to transfer to the USB controller, instead of using the CPU to memcpy() the data to the internal buffer of the hardware in question. Using DMA is how you get performance. I know that Intel has made some lookaside PCI crypto cards and people around IETF is probably aware about that. And you may think why is that not a solution? At first I asked for people that can look inside operating systems source code. Now I ask for people that can look inside CPU's verilog code. I guess the count of people that have these permissions is down to a handful of people in the whole world. My point is, that in order to build an efficient system, you need to look what is below your application, all the way down to the wire actually. You cannot just sit in a JAVA container in a VM, in a cluster, doing crypto using TLS. Because JAVA is safe, VM's are safe and TLS is safe, this solution is then 3x safer than other solutions - right! There are so many insane things going on in the world right now, that are totally not needed, and cause huge resource hogs, like electricity, because the over-all system design is just terrible. If data can be avoid copied to/from the CPU or memory lanes 8 times, then you should get 8x performance on the same system basically. Then 7 of 8 data centers don't need to operate! And this is very difficult to grasp, even for engineers, because you need so much insight. And again those people are very rare from what I can see. --HPS ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes
On 3/24/23 23:59, Watson Ladd wrote: On Fri, Mar 24, 2023 at 2:09 AM Hans Petter Selasky wrote: 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
Re: [TLS] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes
On 3/24/23 09:39, Hans Petter Selasky wrote: On 3/24/23 04:31, Jan Schaumann wrote: Hans Petter Selasky wrote: 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. It sounds to me like this approach makes inappropriate assumptions about end-users' threat models and allows a class of malleability attacks which could range from simple data corruption to - conceivably, under the right circumstances - arbitrary code execution. To me, transport _security_ does indeed require all three of confidentiality, integrity, and authenticity. TLS gives confidentiality. The IP checksum gives integrity. The authenticity part is not needed in my case. A typical video stream of 4 MBit/s may produce on average 333 packets per second, and I ask a simple question if it is really needed to authenticate all of those packets while the user sits in a chair and eats popcorn? 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. I mean, when encryption is recursive, then the outer layers don't need authenticity? Maybe this makes it more clear? --HPS ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes
On 3/24/23 04:31, Jan Schaumann wrote: Hans Petter Selasky wrote: 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. It sounds to me like this approach makes inappropriate assumptions about end-users' threat models and allows a class of malleability attacks which could range from simple data corruption to - conceivably, under the right circumstances - arbitrary code execution. To me, transport _security_ does indeed require all three of confidentiality, integrity, and authenticity. TLS gives confidentiality. The IP checksum gives integrity. The authenticity part is not needed in my case. A typical video stream of 4 MBit/s may produce on average 333 packets per second, and I ask a simple question if it is really needed to authenticate all of those packets while the user sits in a chair and eats popcorn? --HPS ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes
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
