--On Saturday, January 1, 2022 12:03 -0500 Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote: > On 12/31/21 6:04 PM, John C Klensin wrote: > >> Second, I'm not sure what you mean by "OpenPGP over SMTP" but >> cannot think of anything that would prevent defining an SMTP >> extension that asserted that no message was welcome unless the >> content was in OpenPGP (signed, encrypted, or both). > > You don't even need an SMTP extension to do that, you just > need an SMTP server that can be configured to refuse or bounce > mail that isn't signed and/or encrypted. >... Or an MDA or MUA that can do the same thing. My point, again, was that the claim that these things would be done with/over SMTP. I did not claim that it would be easy to get wide adoption (it clearly isn't) or that there were no other issues (there obviously are). The other thing, which I didn't say but hoped was obvious, is that claiming a brand new method with some additional or different features would inherently be easier to deploy on a wide scale than either the existing mechanisms that you pointed out in the rest of your message, Ted pointed out in his, and suggested (especially if the main issue is mail routing or some additional extensions/ twitches to SMTP if they were needed. I think that, ultimately, there are two key problems. First, as you and Ted both pointed out, there is "no way to please everybody", which means that these deployments are all optional and certainly not universal. Second, if we care about identities and authorization (and not only about encryption), then we either need to make credentials and their management easy enough to convince users they care, to be educated about the issues, and to be willing to put in the effort _or_ the situation turns into a "who do you trust" exercise. There are many possible answers to the latter, but the choice will always involve tradeoffs (e.g., not liking governments excludes a large collection of options. Or one can try bypassing part of the problem by saying, e.g., that the first Alice to show up is the real Alice and anyone showing up later must further qualify the name. That, of course, involves its own set of risks and tradeoffs. If there is a magical and painless solution to either of those problems, one that also would scale to a major fraction of the world population or even the Internet user population, it has not been greatly in evidence. And... > A lot of enterprises would probably like to use encrypted mail > but they also want (for arguably legitimate reasons like > looking for malware) to be able to see the outgoing and > incoming content in cleartext. So they might want to > encrypt the outgoing mail after the submission server, and > decrypt the incoming mail after the mail exchanger SMTP server > gets it. >... And that, as you point out less generally (including the exploder problem), turns into another case of "who do you trust" and maybe far more complicated versions of it. > Senders of messages would justifiably want to reliably know > whether the messages they sent would remain encrypted > end-to-end or whether they would be decrypted en route. > The key discovery service could try to provide some indication > of that, but there's no way to prove it. The simplest and > in some sense most honest answer would probably be "we cannot > guarantee that the message is not decrypted en route and if > other servers make such a guarantee you should not trust it". > > This is just an off the top of my head example. But the > point is that if you try to make the ideal system you end up > optimizing for some specific set of use cases, and in doing so > you are very likely to pessimize the system for a lot of other > potentially legitimate use cases. Yep. > I think there's room to add mail encryption to SMTP. The > protocol extensions can be worked out, and major MSPs would > probably find them attractive to their customers. I believe > that doing so would raise the bar for some kinds of attacks > and malicious behavior. But there's no way to please > everybody, and maybe no way to really provide the privacy that > many of us would like to provide. Exactly. And, again, what caused me to make those comments was that, for some definition of "work", one could make encryption in or over SMTP work (and for some definitions and audiences, we already have) and that shifting to a different identifier or mail transport model would not automatically eliminate those core problems no matter how clever the method. john
