You could use a Diffie-Hellman exchange to get a shared secret so things are "obscured by default" but not trusted, then let higher layers deal with trust validation. For example, the TLS certificate handshake could just be a matter of constructing a blob containing the two endpoints' DH public keys and signing it to prove that a man-in-the-middle hasn't intercepted the channel. All the actual encryption would be handled by the IP stack and offloaded to hardware, while the application-layer TLS bits would be used once at startup (and maybe subsequently if the lower layer re-keys) then get out of the way.
Key and cipher negotiation could easily be shoehorned into the three-way-handshake already used to establish connections. AES with a CTR block mode would be the obvious cipher choice since each packet would be handled separately. With TCP you could even just use the sequence number as the counter, although this would be harder at the IP layer.
But yeah, none of this would have been available at the time. Still, given today's technology it would not be difficult to future-proof, especially if the trust machinery is left to the application.
Key and cipher negotiation could easily be shoehorned into the three-way-handshake already used to establish connections. AES with a CTR block mode would be the obvious cipher choice since each packet would be handled separately. With TCP you could even just use the sequence number as the counter, although this would be harder at the IP layer.
But yeah, none of this would have been available at the time. Still, given today's technology it would not be difficult to future-proof, especially if the trust machinery is left to the application.