Re: the introduction problem, was Email and reputation (was Re: Service outages planned for April 25)

[Keith Moore <[e-mail]>]

On 5/2/22 09:20, John R Levine wrote:

> We have several decades of S/MIME and PGP failing because nobody knows 
> how to do key distribution at scale.

I'm not convinced that that's the (only or even most important) reason, 
or that it's even true.   From my perspective there have been several 
barriers to adopting S/MIME and/or PGPMIME, e.g. lack of MUA support, 
lack of email domain CAs and support for them among root CAs, lack of a 
well known and trusted set of root CAs such as exist for the web (it's 
not clear that they should should be the same set), lack of a standard 
key discovery mechanism, and (mostly I suspect) lack of mindshare.

When there are multiple barriers to solving a problem, any one of those 
problems can become an excuse to avoid solving the other problems.

But it seems likely that enterprises could issue email-only certs for 
their employees, and MSPs could issue email-only certs for their 
customers.   There are limitations with that model, especially for 
private individuals.   But such a model could be extremely useful for 
B2B communications, where what you really want to authenticate is not 
the sender's "real name" so much as the sender's role with a company.   
And it could be useful for others also, though not for every conceivable 
purpose.

The biggest problem in generating such certs is arguably that there are 
no established protocols for MUAs to generate keypairs and CSRs, and to 
have them request that the MSP issue certs in response.   There might 
also need to be some new extensions to X.509.   Having the MSP act as CA 
makes sense when the important identity for the user being authenticated 
is their email address and not their name.   Certificates used in email 
need to reflect that (perhaps SAN already does that sufficiently), and - 
more importantly - so do the UIs of the MUAs that interpret those 
certificates.   "Keith Moore" is NOT the same as 
[e-mail] and it's important that MUAs not conflate the 
two.   (MUAs are already notorious for hiding people's email addresses 
from message recipients, by default, whether to save display space or 
out of some misguided notion of usability.)

Even if MUAs had a way to generate keypairs and CSRs and get certs back, 
many people read their mail from multiple MUAs.   So that needs to be 
managed.   Either each user's MUA has a separate key pair, or there 
needs to be a secure way to distribute the user's private key to all of 
the user's MUAs.   I know which one I'd prefer, but either way there are 
details to be worked out.

Of course a "3rd party" cert issued by a trustworthy but neutral CA 
could be useful in addition to these, especially for mail sent by or to 
private individuals.    But email is not like the public web.   The 
model of having a small set of trusted CAs for the web doesn't extend 
well to signing keys used in email from or to private individuals.   I 
used to say that I'd never trust the US Government's certificate for 
Phil Zimmerman's key.  (nowdays I'd probably say Edward Snowden's key, 
but you get the idea).  There is no one party or even hierarchy that is 
sufficiently trustworthy for all purposes.   There are incentives for 
even widely-trusted CAs to occasionally lie about the keys for a small 
number of specific individuals, and less chance that they'd get caught 
doing so when those keys are used in private email than when used on the 
public web.   One party might well want multiple assurances of another's 
public key before trusting that key, but this needs to be made clear in 
their user interface.

User interface issues seem like some of the more significant problems 
because (for example) it really does make sense for the President's 
secretary to sign an email from the President.  How do you communicate 
to users who has the authority to sign something for purpose A but not 
purpose B?  And yet, humans have been doing similar things with 
signatures on paper for many centuries.   I don't think it's an 
unsolvable problem unless perhaps you want to cram all of that 
information on a watch face.

Then there are questions of how encrypted or signed email should 
interact with forwarding and/or mailing lists.   Should encrypted mail 
sent to a mailing list be decrypted by the list and re-encrypted for 
each recipient?   How, again, to communicate to the sender that their 
message is going to a list and that it's entirely up to the list to 
decide how to disseminate the cleartext?   Should the sender be made 
aware of that before composing or at least sending the message?

And then there's the problem of searching encrypted mail in a mail 
store, when you'd like to be able to store the messages as received 
rather than having them be stored in cleartext and accessible to the 
MSP.   Some users, perhaps, will be fine with having their messages 
stored in cleartext; others will not.

And finally there are the various enemies of privacy who will fight any 
effort to make email more secure, no matter how badly it's needed.   And 
they won't be honest about either their concerns or their goals.

***

So I see a lot of careful engineering that's needed, and a lot of user 
interface work (which is admittedly problematic for IETF), and probably 
some hard political work by honest people to overcome the efforts of 
dishonest people who will try to subvert it (whether or not they believe 
they're doing good).

But I don't think there are fundamentally unsolvable technical problems, 
so much as problems that make people uncomfortable - because there's no 
simple system that spans a wide enough range of compromises to suit 
everyone.   But that doesn't mean that there's no system that doesn't 
solve most people's problems.

Keith