Re: [ietf-smtp] Public Key Look Up

[John C Klensin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Following up on the part of this not addressed in my earlier
message...

- - --On Saturday, May 8, 2021 11:17 -0400 John Levine
<[e-mail]>
wrote:

> We have had standard ways to encrypt mail with S/MIME and PGP
> for a long time. It happens in the MUA so the MTAs are outside
> the trust boundaries and see only an encrypted blob of data.
> S/MIME is widely supported on desktop and mobile MUAs (Apple
> mail on an iPad, for example) but hardly anyone uses it which
> should tell us something.

I think we know why it isn't used more often: those end users we
are trying
to protect have not yet started caring; finding, much less
evaluating,
public keys is a PITA; and, even if they did start caring,
teaching those
users to manage keys in ways that would not create their own
security
challenges is, well, difficult.  I could say some nasty things
about
enterprise, MSA, and MDA providers who would be happy to
generate and keep
both public and private keys for people, encrypting and
decrypting messages
as they pass through, but I'll skip it except to suggest that
might not be
much worse than hop-by-hop encryption.

> There are no standard ways to look up S/MIME or PGP public keys
> because secure key lookup is a very difficult problem. How do
> you know you are talking to the "real" key server?

Of course, if you can depend on webs of trust or certificates,
that should
not make much difference.  But that just illustrates a different
part of
the problem.

> Why do you
> believe what it tells you? PGP has its web-of-trust which we
> have repeatedly learned does not scale beyond tiny niche
> communities. S/MIME is TOFU; if I send you a signed message,
> it includes my public key, and MUAs remember the key in the
> address book so you can encrypt mail to me.

And, of course, unless I can verify your signature (and hence
that the
message claiming to be you really is you) that is, as the egg
said to the
chicken, really dangerous.

> Given our decades of failure getting people to use e2e
> encrypted mail I don't see any point in doing it again.  On
> the other hand, channel encryption with STARTTLS is now nearly
> universal since it doesn't depend on users to do anything.

And it creates a point of failure at each relay server that
needs to get
the message it received into cleartext so it can be encrypted
for the next
hop.  In many cases, it is worth doing, but it turns things into
questions
of "who do you truest" and where you think the vulnerabilities
are.   And I
assume that is why Patrick and others (myself included) keep
hoping for a
new invention or a miracle that would enable true end to end,
user-controlled, encryption.  Yes, I would also like a pony, but
I am
willing to keep listening to new ideas in spite of believing
that the
fundamental problem lies in user education and sensitization,
neither of
which I see changing soon.  And that takes us back to where we
have been
for years: if I need to send you something _really_
confidential, I will
ask you for your well-signed PGP key, you will send it to me if
you have
one.  If you don't, or I don't trust any of the signatures, we
will use
some out of band process to either convince me the key you sent
is valid or
to negotiate a shared secret and how we will use it.  Works
fine; lousy
scaling properties.

best,
   john

p.s. And, because I forgot it on the last note, this one is
signed.  I'd
lay good odds that you can find the keys and verify it if you
want to.  I'd
lay much better odds that, if I sent a similarly signed note to
some of my
technology-challenged relatives, they would, at best, ask me
what the
strange gibberish is.


-----BEGIN PGP SIGNATURE-----
Version: Encryption Desktop 10.3.0 (Build 8741)
Charset: utf-8

wsFVAwUBYJbB9rxJD2dVbhZKAQq3uxAAuqzCQP7CY8s6cgIq2TJczQgezE24Ne9B
yBZCQkB4l4Crq5f7o0m7a053ML6/VNOyYzt398Vp22eJTfdavQVq8sSTpEKdi6Og
1yDHnB3655/UQy+ChdV/7rVA1E2uTzxPBPqihWufD9n1c+A6513cOGonkww1Ax0n
4kKsK2pc2xcLJrM/w9/86duOLjpu5HcXcxunYGXKBEtEP1Pi3A+T/1V8aOfM61mK
16UGM4hkWqkQiq5sxJbqcZbP2NKojAvZA5l3u1CPYlaxws4D6KYrh5rQ/ZVWxG1U
7uN2pT4b45ikOmaj4UeqohhshQcvLeBDUfUFtllMcXjsj9Hfk9tQB2ua3HsMJBV5
r70HZqgw2moi9gs189mtX6P/HeUmC9sQJaYHjrHgczvVYGF8i4d/FasrGIUkrNv1
eaOHip4jbyu2nsCl1Rf3rCrIafR1OvC5sU7P55wmRXo5HP2/EdDzV5VPa+5wNoSl
FeqVEZeTokO0fIHCJqCmG5yx4pc+s0uN6Pw9MxHGDZhLebEOcSsjUwlZsCJL+pZ5
IyojLCmmuSlyg7ZK4xxHpkMiMN2zVJTNhcXfc9/5z9S6fT0GL3kqOm7fs4qYIst4
AEWUxnoITtY9xK4YU2SKVF3kFaEfOvNl63KIebAeOl4EgiPxGLXS86hiDnO9tVBg
ONDChZGeGFI=
=xPFE
-----END PGP SIGNATURE-----