If we don't support TLS, doesn't mean we don't care about E2E Encrypted Data, or E2H Encrypted Data, or Signed Data.

I do understand how the system works - and I've seen ISPs issue fake real certificates (which CA issues Google's certificate?) and I think sometimes, you just have to do it deeper, and yourself, if you have to do it right.

I hope I'm parsing this statement incorrectly, but it seems as though you're rolling your own solution to authentication and encryption, rather than using TLS. According to your organization's website, you're an IoT platform. That's terrifying, honestly. I hope I'm misinterpreting something.

A Cortex-M0+ core - which is a really tiny microcontroller - can do TLS 1.2 just fine (using the AES-CCM AEAD instead of the AES-GCM AEAD helps somewhat, apparently: I've not tried to implement it myself, so I'm not clear precisely why, but it's probably GHASH). With enough work, an 8-bit class chip with a couple kilobytes of RAM could implement a constrained subset. If that's somehow still too heavy, I'm not sure how.

I hope they can find a way to make TLS 1.3 work for their IoT scenarios: CHACHA20_POLY1305 and Curve25519 will also hopefully help, quite a lot. They're as small as they are fast.

For AEAD, We'd most likely look at ChaCha20(Poly1305(Text)+Text) and I think that's a great idea. :)

We're definitely looking at non-NIST algorithms, we've just had enough of those.

If you don't support TLS, then browsers won't connect to you using HTTP/2 anyway, so it's a moot point.