Reconsider S/MIME

Issuance Policy
1

Let's Encrypt offering S/MIME has been discussed repeatedly both here and on other forums and social media. The discussion here[1][2][3][4] and elsewhere[5] has touched many aspects of S/MIME. Those aspects combined, LE's stance in the past seems to have been that it's not worth doing.

To me that seems like a mistake, possibly a self-fulfilling one.

The situation with S/MIME right now is that it's, in my opinion, very similar to what HTTPS was ten years ago, or a bit like Ed25519 HTTPS certificates are right now[6].

Lack of a signature is fine[7], acquiring a certificate is expensive, often insecure[8] and laborious. All that while e-mail is often plagued by integrity and confidentiality guarantees. Some of it though can't be fixed by S/MIME, it's certainly not perfect.

When we look at the DV equivalent, "address-validated" certificates, they have the potential to significantly alleviate a bunch of risks for end-users. Without the issues that also once plagued HTTPS deployment. More on that in a later paragraph.

Yes, there absolutely are other technologies like BIMI[9], TLS[10], DMARC[11], SPF[12], DKIM[13], ARC[14] and GPG[15]/PGP[16] that touch and try to secure some aspect or other in the massive intricate system that is e-mail today. There is overlap, dependencies and there's duplication, but in the end, all but the last do what S/MIME intends to do. (I wouldn't dwell long on GPG or e-mail replacements here because they have their, usually bigger, obstacles.)

S/MIME is in a situation where it's unlikely to go anywhere soon, entire countries (yes, literally!) have given people S/MIME certificates, but it's still a relatively niche thing worldwide. Mostly due to the reasons listed above the previous paragraph. Leaving most end-users at the whims of their e-mail provider or enterprise pricing.

Support by LE would mean that e-mail clients (both web and native) have a better reason to support it. Quick ACME request during client setup, why not? Combining previous points, it could mean that end-users and mail clients can start expecting signatures ("Hey, this person has previously signed all their messages and you trust the key, are you sure this new unsigned message is ok?"). When we combine it with new tech such as Certificate Transparency (though, with modifications), it would make it significantly more annoying to forge addresses.

Let's Encrypt is in a position to securely provide generally-available, low-cost and easy-to-use certificates. It absolutely would have a large and prolonged impact on the entire e-mail ecosystem and end-user security, it absolutely should be considered.

  1. https://community.letsencrypt.org/t/153 ↩︎

  2. https://community.letsencrypt.org/t/8351]^[https://community.letsencrypt.org/t/80160 ↩︎

  3. https://community.letsencrypt.org/t/95281 ↩︎

  4. https://community.letsencrypt.org/t/150227 ↩︎

  5. https://news.ycombinator.com/item?id=19795378 ↩︎

  6. Which aren't provided by LE, because CA/B doesn't allow, because there's no point to allow something HSM's don't support, because no large CA or CA/B forum need it, repeat ad infinitum ↩︎

  7. It's unfortunately not uncommon that e-mail is sent without transport encryption not to mention SPF, DKIM and DMARC by some providers ↩︎

  8. Leaf certificate keys are generated by the CA ↩︎

  9. https://en.wikipedia.org/wiki/Brand_Indicators_for_Message_Identification ↩︎

  10. https://en.wikipedia.org/wiki/Transport_Layer_Security ↩︎

  11. https://en.wikipedia.org/wiki/DMARC ↩︎

  12. https://en.wikipedia.org/wiki/Sender_Policy_Framework ↩︎

  13. https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail ↩︎

  14. https://en.wikipedia.org/wiki/Authenticated_Received_Chain ↩︎

  15. https://en.wikipedia.org/wiki/GNU_Privacy_Guard ↩︎

  16. https://en.wikipedia.org/wiki/Pretty_Good_Privacy ↩︎

5 Likes
2

What are the actual requirements, ie: the equivalent of CA/B baseline requirements?

And who is the subject? An email address? An actual person?

2 Likes
3

An email address. An actual person would be out of scope for LE just like EV certs.

3 Likes
4

I see.

But that makes me think: do we need a e2ee system for email that has no forward secrecy at all?

I don't know if that's something that should be made mainstream.

Or if it's even useful, in a world where each MUA-MTA and MTA-MTA link is pretty much using TLS.

2 Likes
5

There are multiple nuances at play here. These use-cases are different, it's a step forward for email even without, it is user preference and people might just wish to sign messages.

Unfortunately that is not the case (otherwise we could collectively actually turn off unencrypted SMTP), you can check out MTA-STS and its deployment for more details. Not to mention how sorry the state of validating certificate subject, usage constraints, validity and transparency is. Neither does transport encryption prove anything about the actual sending domain or sender address.

4 Likes
6

I can imagine they're useful when the email address is actually linked to your identity, but otherwise... I don't know.

It's not ubiquitous but it's pretty common.

2 Likes
7

There are more than a few possible scenarios where an expectation of a signature would make certain attacks more difficult.

It has happened in real life that an SPF/DKIM/DMARC misconfiguration makes it possible for an attacker to send email using certain domain without violating any of the policies. If however the recipient had been accustomed to the sender's email signing, it would have raised suspicion and foiled either an invoice scam or a case of CEO fraud. I've seen scammers walk away with tens and tens of thousands of dollars.

We could, of course blame the providers for setting such a wide SPF policies or leaving DMARC on p=none (let failures trough), but you go try explaining that to Gmail. Plus there are scenarios where even a perfect SPF couldn't have helped (check out the relatively recent FBI website hack).

2 Likes
8

if you hacked the mail server all is lost, attackers can just send/receive challenge mail by themselves.

3 Likes
9

I don't think that's an accurate statement. It'd be more accurate to say that (1) it's out of their scope, and (2) it's not compatible with the real-time, automated validation they do for TLS certs. I'd add to that that, if they were to issue short-lived S/MIME certs, it'd be a royal PITA to deploy those certs across all devices with access to a given email account (in my case, one webmail system, four or more Thunderbird installations on different computers, two smartphones, and two tablets) every 60 days or so.

Now, if there were a way to obtain the cert on the mail host, and deploy it using some sort of autodiscover mechanism the way you can with mail server parameters (though there are at least four "standards" for that), that would help the deployment issue, but now you're storing private keys on the server, so...

5 Likes
10

Their scope is what the decide it to be. "They're not doing it so they aren't going to do it" is tautology.

Not really. Before ACME clients you could've said the same about TLS certs.

In your case, with the software you have right now. Which is a very narrow view really.

Out there, at this point in time, there are existing solutions for S/MIME certificate synchronisation (e.g. Intune Certificate Connector, but there are a bunch of others), albeit they're mostly aimed at corporate settings they exist. Nothing dictates that something similar couldn't be made for regular users. Not to mention the possibility of using multiple certificates.

In the end though we have a good case study of how it could be done. Password managers to synchronise passwords, secret notes, sometimes even TOTP keys are a really common thing. Those really aren't a PITA or are they?

It would be nice to avoid these kinds of artificially constructed chicken/egg-style obstacles when discussing this.

1 Like
11

No, please. Their scope is not "anything they decide it is"

Their scope is bringing TLS to the masses, it's an explicitly mainstream vocation.

Now, the point isn't really wether S/MIME is a good idea or it's easy to implement, the point is wether it's something that brings a clear and important privacy/safety improvement to mainstream users.

Always remember that Let's Encrypt's workforce is less than 20 people. They can't just do something just because they like it.

3 Likes
12

Well, yes, it'd be nice to be able to live in a fantasy world--but I try to live in the real world. In the case of TLS certs, their use ought to be transparent to clients; the only ones who (should) need to worry about them are server administrators. But S/MIME certs are for the end user. And you've just said that, to make them practical for "regular users", a whole ecosystem of software needs to develop to, among other things, synchronize certificates among multiple devices, automate the acquisition of certificates, and automate the renewal of certificates. And every single user (who wants such a cert) will need this software. This is a problem orders of magnitude greater than that of deploying TLS certs, so no, I won't accept hand-waving it away with "it would be nice to avoid" the real world.

3 Likes
13

How is that a requirement?

I would think that just as being able to issue the exact same cert (name) five times in a week (and use them all on different devices), one could issue "duplicate" and "individualized" S/MIME certs.

I really think that current "email security" is almost non-existent and would benefit from "cheap" S/MIME.

4 Likes
14

the hairy thing about s/mime is other side can send a email encrypted by smime's cert's public key, so if client doesn't have that cert's private key you won't be able to read the mail
(this applys to expired certificate too, so you have to keep old certificate pack around to decrypt old email)

3 Likes
15

That sounds like true end-to-end encryption (to me).
Meaning: You could use even YAHOO! email and still feel safe about no one reading your messages.
#AOL_You've_Got_Mail

3 Likes
16

it's end-to-end, except no forward security because you will need to read mail later

3 Likes
17

now this makes we wonder if we could attempt to automate personal verification with things like digital passport + phone sms verfication or something standardlized document?

2 Likes
18

If I have five different certs on five different devices (ignoring expiration), and someone sends me an encrypted message, I can only read that message on one of the devices--the other four won't be able to decrypt it.

Can you work around that? Sure--use the same private key across all those devices, the certs will contain the associated public key, and Bob's your uncle. But you're back to the problem of keeping that private key in sync.

S/MIME can work well in a closed ecosystem. For example, I work for the US Government (and naturally I don't represent my employer here). My employee ID card is a smart card containing authentication, signature, and encryption certificates, everyone else has one, and all our computers trust the Government CAs--and all of the certificates are stored in the Outlook address book, so I can send encrypted email to anyone else in my agency, and anyone else in my agency can verify my signed emails. The only technical knowledge I need is to click the "encryption" button in Outlook. But for that to work, you need a PKI set up to deal with it, and certificates need to be portable.

5 Likes
19

I'm not hand waving it away, I was saying you weren't aware of (or decided to ignore) current solutions, you were ignoring the alternatives and currently available software that goes half of the way.

You're saying it like it's nearly impossible to do, here, at Let's Encrypt's forum. I hope you are aware that most of what you're describing had to be implemented for TLS certificates as well.

How email clients decide to finally integrate ACME clients is up to them, it would take time obviously. But it also wouldn't be long until the first. Issuance is one thing, "key vaults" another, but password managers are very much here already - it absolutely wouldn't be difficult to extend that.

It's utterly ridiculous to expect perfect infrastructure to exist to support a thing that doesn't exist, then use that lack of infrastructure as a reason why not to provide that option. I won't accept circular reasoning as to why something can't be done.

1 Like
20

It pretty much depends on how Google decides to support it in the Gmail web client.

Without some kind of strong industry buy-in, and because the advantages of S/MIME are marginal, I really don't really see a global switch to e2e encrypted email in the future.

I mean, S/MIME is only used in enterprise settings and in some countries "certified email" (1) systems -- in neither of those cases you directly control the key generation or handling, it's either on the provider's system (and I really hope it's on an HSM because otherwise we're fucked) or on your smartcard.

When you go in the public space, github and facebook ask for an email encryption key to send you encrypted notifications -- but it's an OpenPGP key.

(1): that are not e2ee: signing, verification and eventual encryption happens at the MSA/MTA/MDA level. -- and they also guarantee delivery, and read receipts. It's a thing designed by lawyers and governments just how they like it.

2 Likes