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 Mon, Mar 27, 2023 at 4:48 PM Watson Ladd wrote > > No. XDP is acting as a firewall and Tubular is mapping packets to sockets. > The TCP is handled by the kernel and given to the application through the > usual interfaces. > > That's different from DPDK where the application is completely responsible > for all handling of packets and the kernel just shoves a ring buffer at it. > > That sort of offload exists, but I don't think it's terribly common. > Obviously how you measure it is hard and we mostly have anecdotes. > It's in the definition, right? https://en.wikipedia.org/wiki/Express_Data_Path The point is to bypass the typical kernel networking. I agree that there are different ways of doing this, and this method reuses more kernel code than others. But it's still not using the kernel code in the way that you would get by default. thanks, Rob ___ 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 Sun, Mar 26, 2023, 7:03 PM Rob Sayre wrote: > > > On Sun, Mar 26, 2023 at 6:51 PM Watson Ladd wrote: > >> >> >> On Sun, Mar 26, 2023, 5:05 PM Rob Sayre wrote: >> >>> Hi, >>> >>> The problem is also incompletely described, right? >>> >>> It doesn't address stuff like: >>> https://github.com/F-Stack/f-stack >>> >>> There, you have userspace networking right off the NIC using DPDK or >>> equivalent. This is how all big websites work (this one is from Tencent), >>> because it's easier to drain connections as you upgrade the software, and >>> it's fast enough to saturate the network hardware. >>> >> >> That's not quite true: e.g. Netflix is just kernel+TLS offload to >> kernelspace+nginx+sendfile. DPDK draining can be messy while passing the >> opened listening sockets NGINX style is pretty clean. >> > > Yep, another replier person went with the Netflix example (a strong one, > but kind of an outlier). > > > Cloudflare is XDP to kernel stack to application, at least as of the blog >> post I read before posting. >> https://blog.cloudflare.com/tubular-fixing-the-socket-api-with-ebpf/ >> > > Sure, but isn't that the same idea? > > https://en.wikipedia.org/wiki/Express_Data_Path > > "XDP (eXpress Data Path) is an eBPF-based high-performance data path used > to send and receive network packets at high rates by bypassing most of the > operating system networking stack." > > It's exciting that this idea is becoming more of an off-the-shelf > proposition, though. > No. XDP is acting as a firewall and Tubular is mapping packets to sockets. The TCP is handled by the kernel and given to the application through the usual interfaces. That's different from DPDK where the application is completely responsible for all handling of packets and the kernel just shoves a ring buffer at it. That sort of offload exists, but I don't think it's terribly common. Obviously how you measure it is hard and we mostly have anecdotes. Sincerely, Watson > > thanks, > Rob > > ___ 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
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? Are there any 0-day exploits in your video system? Is that middle box doing the right thing? 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. Does your popcorn eating user need TLS as all? -- These are my opinions. I hate spam. ___ 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 Sun, Mar 26, 2023 at 6:51 PM Watson Ladd wrote: > > > On Sun, Mar 26, 2023, 5:05 PM Rob Sayre wrote: > >> Hi, >> >> The problem is also incompletely described, right? >> >> It doesn't address stuff like: >> https://github.com/F-Stack/f-stack >> >> There, you have userspace networking right off the NIC using DPDK or >> equivalent. This is how all big websites work (this one is from Tencent), >> because it's easier to drain connections as you upgrade the software, and >> it's fast enough to saturate the network hardware. >> > > That's not quite true: e.g. Netflix is just kernel+TLS offload to > kernelspace+nginx+sendfile. DPDK draining can be messy while passing the > opened listening sockets NGINX style is pretty clean. > Yep, another replier person went with the Netflix example (a strong one, but kind of an outlier). Cloudflare is XDP to kernel stack to application, at least as of the blog > post I read before posting. > https://blog.cloudflare.com/tubular-fixing-the-socket-api-with-ebpf/ > Sure, but isn't that the same idea? https://en.wikipedia.org/wiki/Express_Data_Path "XDP (eXpress Data Path) is an eBPF-based high-performance data path used to send and receive network packets at high rates by bypassing most of the operating system networking stack." It's exciting that this idea is becoming more of an off-the-shelf proposition, though. thanks, Rob ___ 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 Sun, Mar 26, 2023, 5:05 PM Rob Sayre wrote: > Hi, > > The problem is also incompletely described, right? > > It doesn't address stuff like: > https://github.com/F-Stack/f-stack > > There, you have userspace networking right off the NIC using DPDK or > equivalent. This is how all big websites work (this one is from Tencent), > because it's easier to drain connections as you upgrade the software, and > it's fast enough to saturate the network hardware. > That's not quite true: e.g. Netflix is just kernel+TLS offload to kernelspace+nginx+sendfile. DPDK draining can be messy while passing the opened listening sockets NGINX style is pretty clean. Cloudflare is XDP to kernel stack to application, at least as of the blog post I read before posting. https://blog.cloudflare.com/tubular-fixing-the-socket-api-with-ebpf/ > I don't mind the kernel hacking rhetoric, but no one with a serious load > does this. (or, if you do, look at that f-stack link...) > Even in userspace you have the same issues with the NIC/software interface. > thanks, > Rob > > > On Sun, Mar 26, 2023 at 3:00 PM 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. >> >> >> On Sat, Mar 25, 2023 at 12:41 AM Hans Petter Selasky >> wrote: >> >>> 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. >>> >> >> 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 >>
Re: [TLS] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes
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 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 > wrote: > >> 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. >> > > 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
Re: [TLS] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes
On Sun, Mar 26, 2023 at 6:06 PM Patrick Kelsey wrote: > Absent that one giant slice of internet traffic, I would agree your point > does broadly apply (and I'm well familiar with user-space networking - for > example, the core of f-stack project you mentioned was originally > misappropriated code of mine). > That sounds like a lot of traffic, but not a lot of handshakes. But even then, I'm sure the Netflix problem is not an easy one, even though it must be about serving the same popular files rather than opening and closing connections. I'm glad you agree in general. I don't know anything about the attribution for f-stack, it said it was BSD-2 licensed. But I also don't use it. It's a good open source example. thanks, Rob > > Best, > Pat > > On Sun, Mar 26, 2023 at 8:05 PM Rob Sayre wrote: > >> Hi, >> >> The problem is also incompletely described, right? >> >> It doesn't address stuff like: >> https://github.com/F-Stack/f-stack >> >> There, you have userspace networking right off the NIC using DPDK or >> equivalent. This is how all big websites work (this one is from Tencent), >> because it's easier to drain connections as you upgrade the software, and >> it's fast enough to saturate the network hardware. >> >> I don't mind the kernel hacking rhetoric, but no one with a serious load >> does this. (or, if you do, look at that f-stack link...) >> >> thanks, >> Rob >> >> >> On Sun, Mar 26, 2023 at 3:00 PM 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. >>> >>> >>> On Sat, Mar 25, 2023 at 12:41 AM Hans Petter Selasky >>> wrote: >>> 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
Re: [TLS] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes
Hi Rob, Without wading into the other technicals of the discussion at this point, I just wanted to comment that there is at least one significant exception to your absolute statement below ( "no one with a serious load..."), and it's quite possible given the circumstantial information here that this particular exception may be what's motivating this thread, or is at least closely related. The Netflix Open Connect Appliances, last I saw published, were closing in on 1 Tbps of TLS from a single chassis and are pretty well known to have been architected without user-space networking. Absent that one giant slice of internet traffic, I would agree your point does broadly apply (and I'm well familiar with user-space networking - for example, the core of f-stack project you mentioned was originally misappropriated code of mine). Best, Pat On Sun, Mar 26, 2023 at 8:05 PM Rob Sayre wrote: > Hi, > > The problem is also incompletely described, right? > > It doesn't address stuff like: > https://github.com/F-Stack/f-stack > > There, you have userspace networking right off the NIC using DPDK or > equivalent. This is how all big websites work (this one is from Tencent), > because it's easier to drain connections as you upgrade the software, and > it's fast enough to saturate the network hardware. > > I don't mind the kernel hacking rhetoric, but no one with a serious load > does this. (or, if you do, look at that f-stack link...) > > thanks, > Rob > > > On Sun, Mar 26, 2023 at 3:00 PM 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. >> >> >> On Sat, Mar 25, 2023 at 12:41 AM Hans Petter Selasky >> wrote: >> >>> 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
Re: [TLS] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes
Hi, The problem is also incompletely described, right? It doesn't address stuff like: https://github.com/F-Stack/f-stack There, you have userspace networking right off the NIC using DPDK or equivalent. This is how all big websites work (this one is from Tencent), because it's easier to drain connections as you upgrade the software, and it's fast enough to saturate the network hardware. I don't mind the kernel hacking rhetoric, but no one with a serious load does this. (or, if you do, look at that f-stack link...) thanks, Rob On Sun, Mar 26, 2023 at 3:00 PM 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. > > > On Sat, Mar 25, 2023 at 12:41 AM Hans Petter Selasky > wrote: > >> 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. >> > > 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. > >
Re: [TLS] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes
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 wrote: > 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. > 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 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 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? Sincerely, Watson Ladd -- Astra mortemque praestare gradatim ___ 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
Re: [TLS] [TLS-NO-AUTH] Proposal to skip TLS authentication for entertainment purposes
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. -Jan ___ 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
