[Coco] Tcp off-loading on CoCo

[William Astle]

On 2017-04-09 09:53 AM, Brett Gordon wrote:
> Modern internet pretty much will require TLS and oauth for the coco to do
> anything internet related (twitter,gmail,fb,  etc.).   This would seem to
> make tcp offloaders like wiznet, or esp8266 less desirable?  I'm finding
> plain tcp has limitations:  many inet services pretty much require a secure
> and authenticated connection.

TLS is the big thing that's actually needed to access many extant 
internet services. It is not, however, a network stack protocol (believe 
it or not). It operates *above* TCP, and sometimes even above an 
additional application layer. That means a TCP offloader is still useful 
since it takes the work of dealing with the actual TCP protocol off the 
Coco, and that's nothing to sneeze at. Whether that offload is handled 
by a hardware device with esp8266 or something like Drivewire, it's 
still beneficial.

TLS is not required for things we develop ourselves for the Coco. That 
is, if you're making a server side application on Fuzix, say, you don't 
have to worry about all that. The application maker gets to choose 
whether the encryption junk is required, or whether fancy things like 
OAUTH are.

Thus, TLS is mostly required for client-side operations reaching public 
services. How many of us are going to use web browsers running on the 
Coco, realistically? Probably not many. It's really something of a 
whistling dog situation. (And, the javascript and graphical requirements 
to use many of those sites are pretty heavy anyway.) The same goes for 
email access using POP3/IMAP/SMTP.

Still, here's my take on doing that if we want:

TLS is an application layer protocol. As far as TCP is concerned, it's 
just the connection payload. The client and server applications are the 
ones that decode it. It happens entirely in userspace modulo any crypto 
accelerators that might be in use.

Presumably, the Coco could be taught to do TLS if the memory 
requirements are not too high. Obviously that wouldn't be using a 
library like OpenSSL or GNU TLS or the like since those are likely far 
too big. It would have to be far more focused so it didn't overflow the 
available resources on the Coco. (Say by only implementing a current 
version of TLS and ignoring all the old junk, and only implementing a 
selection of ciphers.) If that is even possible. I can see how this 
would probably best be done in a way that allows for an offload of the 
TLS operations to a device of some kind (or at least to a separate 
process). (Usually, TLS libraries work as a shim between the real 
communication channel and the application anyway so that's likely not so 
difficult.) The thing to remember is that not every connection that uses 
TLS immediately starts up using it. It can be added later in some 
protocol specific way in many cases (notably SMTP and IMAP support this, 
but there's even a way in HTTP).

Once TLS is cracked, though, absolutely everything else is definitely 
application layer. OAUTH is built on top of the web browser and works 
using HTTP redirects and a server<->server exchange in the background. 
The client side doesn't need anything beyond a functional browser that 
supports redirections, HTTPS, and probably cookies. The server side is 
heavier, but remember, if we're making the application, we can choose 
not to require something like that.

Basically, the point of this is that TCP offload is still a good idea. 
If you can somehow offload the crypto stuff in a useful way (it can be 
turned on and off mid-stream), too, that would likely also be helpful. 
The crypto offload need not be the same device, though.