By secure I mean at least confidential, authenticated, and repudiable. So no one can read the data sent between A and B, B knows that it is communicating with A, and B cannot prove to anyone else that A sent particular data.
There are more formal/rigorously defined terms for this and variations. You can google IND-CCA to start digging in.
By default I mean that the least complicated, easiest to use, front-and-center API establishes this sort of connection with the 2nd party. And sending insecure data becomes akin to dealing with raw ethernet frames, possible, sometimes necessary, but not even allowed on most operating systems without elevated privileges. Concretely that might look like replacing `dial(host, port) -> Conn` functions with `dial(publicKey, host, port) -> SecureConn` functions.
I'm confused as to why you think you can replace all the things in TLS that provide security with some sort of magical SecureConn function. TLS is the secure connection, so much so that your code example is exactly what happens in Golang when you use the TLS library. net.TLS provides a Dial() and a net.Conn implementation.
Your argument seems to be "TLS is bad because it is complicated. We should replace it with something logically equivalent, but better in some way that I have not defined." This is a fundamentally unserious argument, unless you can say what is wrong and what the requirements for a new solution are that are not provided by TLS currently.
Go write up the code to connect two parties. Just A and B. A knows about B and wants to connect to B specifically, B will talk to anyone, but wants to know exactly who. It's far more than just Serve and Dial, and often you have to involve a 3rd party, or know a lot of details about self-signed certificates and the particulars of authenticating them.
If it was just Serve and Dial with the guarantees I mentioned, we would be in agreement that it was easy and a suitable default.
> "TLS is bad because it is complicated. We should replace it with something logically equivalent, but better in some way that I have not defined."
I thought I was fairly clear in saying: less complicated == better. That is the way in which it is better, that I am now defining explicitly for you. If that's controversial then that probably explains most your disagreement. The complexity has to be so low relative to other solutions that it is more likely to be used than not.
I agree that simpler is better than more complex, but you're not saying what is wrong with the current approach. I gather you're upset about certificates (who isn't annoyed with X509?), but ultimately all you're saying is "I wish Serve and Dial were more secure, but without using the mechanism that specifically exists to make them secure." This is just one big No True Scotsman.
There are more formal/rigorously defined terms for this and variations. You can google IND-CCA to start digging in.
By default I mean that the least complicated, easiest to use, front-and-center API establishes this sort of connection with the 2nd party. And sending insecure data becomes akin to dealing with raw ethernet frames, possible, sometimes necessary, but not even allowed on most operating systems without elevated privileges. Concretely that might look like replacing `dial(host, port) -> Conn` functions with `dial(publicKey, host, port) -> SecureConn` functions.