I have an embedded system product that emails out event notifications periodically. I have implemented a non secured email version, but want to use SSL/TLS, if possible. Can I only use 1 cipher suite for space considerations? Or, do I have to support many types? I'm trying to keep it simple, but not sure if there will be issues with just one or a couple. Any input on how others would handle a simple one-way email feature using SSL/TLS?
You can support as many or as few as you like - take a look at RC 5247 for TLS 1.2. If you are on an embedded system w/o any hardware crypto, you may want to skip the RSA algs that take a long time in favor of the ECDH. In any case, look for an embedded crypto library that available for your toolchain and cpu vs writing it yourself. It'll save time as well implementation flaws.
You might try initiating a TLS session with one of these email hosts and see what comes back for the algorithms they support - I suspect it's pretty extensive. Then you could be sure that the ones you pick will work.
Wireshark is your friend for this.
For each server that you product will communicate with, your product needs to have a ciphersuite in common with that server. If you have some control over the servers, then it's perfectly fine to pick one ciphersuite and require that the servers must support this ciphersuite. If possible, however, it would be better to support at least two different ciphersuites; that way, if one of them turns out to be broken, the other one may be a suitable fallback. If your product needs to interact with other people's servers,
RFC 7925, which is intended to apply to low-end devices, recommends the use of ECDHE (specifically
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8) with the curve secp256r1. Mozilla has somewhat different recommendations, with a preference for GCM-based ciphersuites (see Security of authenticated encryption modes GCM & CCM and How to choose between AES-CCM and AES-GCM for storage volume encryption regarding CCM vs GCM; it isn't a decisive factor in security but GCM might offer better performance). Servers that seek browser compatibility with a restricted set of ciphersuites might be more inclined to support only one or a few of these.
Note that using TLS for email isn't a panacea, because it only secures the connection to the first hop. The email is only protected if all the hops on the email's path use TLS and all the intermediate servers are trusted, which in general is difficult to ensure. Unless your product operates in a closed environment where the path of an email is guaranteed to go through trusted servers only, to achieve confidentiality and authenticity of the email, you need some form of end-to-end protection. This is typically done with either PGP or S/MIME. TLS on top of that does have some advantages (confidentiality of the headers, which in particular provides privacy regarding the sender and the recipient up to what is revealed by the email's path; also, protection against replay), but all these advantages only hold only inside the domain where all email servers are trusted, they're lost as soon as the email hits an untrusted intermediate server, as is the confidentiality and authenticity of the body.