Reasons for SSL:

• Security

• The server you speak with requires SSL

Reasons for no general purpose OS:

• Limited power (battery, solar)

• Extreme cost pressures (linux needs about $5 of hardware)

• Security (smaller code to audit)

• Extreme reliability requirements

So anything that ticks a bullet in each category is a candidate.

• Remote sensors

• Radio gateway, say LoRa to an internet server

• A device which keeps a secret for you and provides it to a server on command, perhaps something in a 2FA vein.

• Remotely triggerable actuators (door locks, parking lot lights)

I very badly need a TLS library in my embedded firmware so I can accept new firmware updates over HTTP.

You don't need TLS for that, you could simply use an HMAC and a shared secret, assuming you're not worried about people with physical access (and ability to get the secret) being able to create updates. Of course if you've got multiple instances of the device (not some hobby thing where they are all owned by you), then the secret for each device should be different so someone can't buy the device, determine the secret and then push updates to other people's devices.

Wouldn't signing each release with a private key be the simplest solution here?

(that can take many forms, but that general idea is how most software updates currently work)

RSA means big integer which means unhappy performance on devices that often don't even have floating point in hardware. I think elliptic curve could be faster?

> I think elliptic curve could be faster?

Yes, EdDSA is faster, with 64 byte signatures. Recommended.

https://en.wikipedia.org/wiki/EdDSA

Verifying a signature is not the simplest thing to do on hardware that doesn't even support a normal OS.

I see, that makes sense. Let's say you implement verification as:

1. Hashing the incoming data

2. Decrypting an attached signature

3. Verifying the decrypted and calculated hash are the same

Even though Step 2 would involve RSA or ECC, wouldn't Step 1 be the most expensive part regardless?

Yup you are right.

Not a very good idea, for the very reasons you point out. Signed releases with public keys, as conradev points out below is the far better approach.

Besides of what was already mentioned:

Many automotive or industrial communication buses are currently unencrypted, but could surely benefit from encryption.

probably could be useful in some small "internet of things" device

This. Internet of Things especially can benefit from adding TLS.

However you would often want DTLS there, which is for example what CoAP (HTTP-like IoT protocol which is based on UDP) uses.

i would imagine as some sort of secure-boot or trusted hardware process.

Lots of things with microcontrollers.