Isn’t the recommended approach to use application-level encryption in MQTT? That seems mostly fine to me for a spec with simplicity as a goal.

It's also trivial to tunnel an unencrypted protocol over TLS.

https://man.openbsd.org/tls_connect.3

Or even

https://www.stunnel.org/

I ran into a lot of difficulty when dealing with devices that needed a bridge to access the internet. So device doesn’t have a tcp stack and requires a socket-like connection to an intentional-man-in-the-middle.

Implementing payload end to end encrypted MQTT was easy enough.

Any thoughts on TLS for that scenario? At best I could have a simulated socket, but always to an untrusted middle man.

Turns out ONE answer is that DTLS is TLS for datagram connections (ie: UDP) and it’s pretty easy to forward along UDP packets at a proxy (as there is no need at all to track what sent or needs a retry).

It should be noted (if anyone reads this) that DTLS has protections and reliability on packets to establish the connection, but once it’s established it just goes back to being UDP although now encrypted, so you need to be ok with losses.

If you need messaging on top of that, CoAP adds in the counters and retries and reliability to UDP. Making UDP a little more like TCP but features to get this are one level higher in the CoAP packet. It’s a little weird, but gets you relatively reliable request/response HTTP-like (CoAP CONFIRMATION) and also event driven async MQTT-like (NON-CONFIRMATION). So that’s pretty cool.

Although near for me as GCP and Azure support CoAP but for some reason Amazon seems to refuse to and I’m locked in to Amazon for other reasons.

You're not going to be running openssl or stunnel on an 8-bit microcontroller, though.

mbedtls/polarssl is usually the library of choice for microcontrollers (or, really, things that are not POSIX), but not sure even that will run on an 8-bit micro.

> You're not going to be running openssl or stunnel on an 8-bit microcontroller, though.

True, you may need BearSSL, as with this port: https://github.com/OPEnSLab-OSU/SSLClient

It's a bit fat for many 8 bit microcontrollers -- needs 110kB flash and 7kB RAM -- but you can get low end cortex cores that it'll work just fine with.

But that’s negate many of the benefits of quic!

>"trivial to implement" if you don't need encryption. Which you kinda do most of the time. Not everything runs in the design constraints of an 8bit micro.

What? Encryption is a completely different step from framing and message semantics.

>It would also be nice if you'd at least pretend to engage with the arguments in the paper, instead of making up imagined reasons.

This is just absolutely silly and stupid. HTTP3 is not tied to the encryption used. I suggest you review your understanding before contributing more.