The reason to put encryption at the bottom of the stack is that it helps with Hyrum's Law. Part of the reason TLS is so hard to change is that everyone can see all the data and therefore anyone on the path your package takes might make decisions based on the data. This code will break if you try to update anything (even if the thing they are observing is something that they shouldn't have been observing). By encrypting everything possible, you remove the ability for everyone in the middle to see or depend on any details of the higher layers.

Enjoy debugging things when everything is encrypted... and then your certificate provider goes down (or removes you because they don't like you) and you can't even connect...

Look at the ones pushing this stuff, who they work for, and what interests they have. It's easy to see why a lot of things are the way they are, when you realise their true purpose.

> 2) Encryption is needed in the bottom stack! WHY?

One reason is that hardware (NICs) can offload encryption more easily when it's closer to the lowest end-to-end layer (i.e., no lower than IP).

So IPsec and QUIC are easy to offload, but TLS-over-TCP less so. It especially helps that there is no need to buffer up part of the TCP stream so as to get whole TLS records to decrypt.

You don't need hardware encryption if you don't need encryption.

You are solving 1% of the problems with 99% of the energy.