I think it’s fine if you want to be concerned about spying, but it’s important to be concerned about the right things. A short certificate cycle isn’t one of those.
The mechanisms behind PKI and how SSL/TLS work over HTTP are well known. The mechanism itself is sound, as no cryptographer has raised concern over it. What concern has been raised over falls into a few categories: interception (man in the middle) attacks, information leakage and weak cryptography. All major attack categories require interception abilities of some sort, so keep that in mind.
Man in the middle, or MITM is fairly simple to understand. Basically, you convince both parties in a two-party conversation that they are talking to the other person but relay information between the other. This puts you in the middle of the conversation with the ability to intercept both sides and remain hidden. Usually this relies on having a trusted certificate on the client end of the conversation and the ability to route traffic through a relay that the attacker owns. You’re looking at having to be on an untrusted or compromised network and trusting the attacker’s CA. This isn’t fully relevant for our concerns here and it’s certainly not something specific to Let’s Encrypt, so we should move on to the other classes of attacks.
Now, information leakage is a much more subtle issue. There are things called timing attacks that can exploit knowledge in how long certain cryptographic procedures take to determine what the plain information may have been. Sometimes you can get enough information to even uncover the private key being used on the server. This is more common with certain encryption algorithms (see the weak crypto explanation below), so many libraries take great pains to randomize the length of operations. Once again, this isn’t anything that Let’s Encrypt can control. It’s something down to how OpenSSL/LibreSSL/BoringSSL, GnuTLS, NSS, or SChannel work. Another information leakage style is via electromagnetic emissions. Every key you press on your computer and every pixel combination on your screen have a very specific signature. If someone with good equipment parks outside your house and scans for your computer, or even taps into your power line, they can figure out what’s on your screen and what you’re trying. See TEMPEST for more information. This is also not something Let’s Encrypt can control.
The most important category is weak cryptography. No matter how much care you put into other areas, they won’t help against weak cryptography. This is where flaws in certain cryptographic functions or just advances in computing power can expose your encrypted data. There really is no preventing this on a long-term scale; computers will continue to become more powerful and very smart people will get more familiar with certain math operations and find shortcuts. The only protection is to use the strongest practical security you can at the present time. It’s why you can no longer get a certificate from anyone if you’re using a 1024-bit RSA key. That size of key has become practical to brute-force with enough compute power. It’s why you don’t want to use MD5 or SHA1 to hash passwords; it’s too easy to generate possible combinations and brute-force the original text. It’s why more and more cryptographic algorithms are invented and tested in an effort to find something even more difficult to break.
So, where does this leave us? Well, based on the most important category of weak cryptography, it’s smarter to use shorter-term certificates. If everyone is using short-term certificates unless they have a very good reason otherwise, flaws can be stopped much much quicker. Should some weakness be found, like in SHA1, you can replace almost all the certificates out there in less than a year. It’s taken multiple years to even start to fix the SHA1 issue as it is, and only because the browser makers (mostly Google) have decided to publicly shame sites using insecure certs. As a bonus, if you change your key every renewal, even should that key be found by some other means where the operator of the server is unaware, it’s only going to be used for a very short time before being replaced. This makes long-term surveillance very expensive as that new key will have to be found every time it’s replaced. A key used for a three-year certificate that is found a month after being used will be good for 2 years 11 months. For a 90 day certificate, it’s only good for two months (or less if you follow the renew at 60 days recommendation)! Even with a one year certificate in the same situation, the short-term 90 day certificate with a new key will be 4-6 times more expensive to surveil for the same period!
Now we turn to where we really should worry. The first is that our private key is exposed. If we choose not to trust the Let’s Encrypt reference client, we’re still okay. The protocol being used is an open reference and you don’t have to use that client. You run the whole process manually or even build your own client that you trust to keep your private key from being transmitted. Nothing in the CSR that Let’s Encrypt gets has any kind of private information.
The only thing you then need to worry about are backdoors in other software you trust, like the cryptography library you’re using or someone breaking into the server and exfiltrating the keys.
tl;dr: The only thing to really worry over is the LE client, but you don’t have to use it. 90 day certificates are not an issue.