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
