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.
The missing piece is a public key+cert discovery mechanism. This can
also be added to SMTP.
Then you need mail user agents that query recipients' SMTP servers to
find the recipient's public keys+certs, and verify the keys used to sign
the certs as being trusted.
Then it gets messier.
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. So they'd at least want copies of the private keys, even if they
forward incoming mail to its destination with encryption intact. Since
the enterprises at least in theory control their SMTP servers that would
also be used for key discovery (as well as the DNS names used to find
those servers), they can enforce such a restriction.
Individuals don't want their MSPs to have their private keys. It's
possible that MSPs (at least in certain countries) would use the same
mechanism as enterprises to force disclosure of private keys. In
theory individuals can have their own DNS names and set up their own
SMTP servers. (making this manageable by ordinary people at scale is
still an unsolved problem but might be solvable) But oppressive states
would probably try to thwart that.
Decrypting messages prior to delivery might be attractive to some
individuals and enterprises so that MUA searching of messages for
content would still work. Making searching work efficiently on a
message store full of e2e encrypted messages is ... difficult.
There's also a question of mail that's automatically forwarded from its
original address to one or more new destinations (including mailing
lists). Should it be decrypted before forwarding, and perhaps
re-encrypted for the new recipient(s)? The right answer might not be the
same for all cases.
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.
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.
Keith
