Subject: [ietf-smtp] Public Key Look Up

From: [email-masked]
Date: Sat, 08 May 2021 14:03:45 +0000

Hi,

This is my first email to this mailing list, so apologies in case it does not follow any specific standard procedure. It is however a genuine thought and hope it is relevant to the SMTP standard.

Some context -

With rising data privacy concerns, more and more users are starting to adopt end-to-end encrypted communication methods or zero-knowledge solutions. However the interoperability of related services remains very limited.

Specifically looking at end-to-end encrypted email providers, the general implementation approach follows the below high-level workflow -

- Consider that Bob would like to send an end-to-end encrypted email to Alice
- Bob creates a new draft email in the email interface of his preferred end-to-end encrypted email provider
- While Bob drafts his email to Alice, all draft versions are stored encrypted in Bob's server side draft email folder using his own public key
- Once Bob finishes his email to Alice and selects the send option, his email application retrieves the public key for Alice, encrypts the email with her public key and transmits the email using the standard email protocols available
- In parallel a copy of the sent email is stored in Bob's sent items, again encrypted with his own public key

Since the availability of the recipients public key is fundamental to such end-to-end encrypted email implementations, the interoperability between end-to-end email providers depends on standards for public key exchanges. It is hereby assumed that the actual used crypto-system for encrypting emails using the public keys, does not represent a challenge for email providers.

In order to address this interoperability issue in a standards centric approach, the proposal is the addition of a new SMTP command to allow the retrieval of a recipients public key prior to the transmission of a mail. This will enable the sender to encrypt the email content before the same is transmitted through the existing SMTP commands.

Such a Get Key (GETK) or Public Key (PKEY) command in the SMTP standard would take an email address as a parameter and if implemented return the public key the mailbox user.

As the SMTP standard is widely adopted, the introduction of such a command could exponentially increase the adoption of more secure email communication. Alternative options such as the use of separate and dedicated key stores to solve this issue have not only be unsuccessful to drive higher security for email communication, but they also operate outside of the established standards and infrastructure deployed by email providers across the globe.

Even for using utilizing encryption programs that operate outside of the email ecosystem, e.g. PGP, such an extension can provide more trusted option to retrieve the public key from the recipients email provider.

Many thanks for your consideration.

Best,

Patrick P

---

From: Jeremy Harris <[email-masked]>
Date: Sat, 8 May 2021 15:43:06 +0100

> In order to address this interoperability issue in a standards centric approach, the proposal is the addition of a new SMTP command to allow the retrieval of a recipients public key prior to the tr…

This requires the MUA to be a full MTA not just an MSA passing off outbound
traffic to a real MTA,  Not the current usual architecture.

It also doesn't work with traditional-forwarding, I think, unless the forwarder
decrypts and re-encrypts.
-- 
Cheers,
   Jeremy

---

From: "John Levine" <[email-masked]>
Date: 8 May 2021 11:17:44 -0400

It appears that Jeremy Harris  <[email-masked]> said:
>> In order to address this interoperability issue in a standards centric approach, the proposal is the addition of
>a new SMTP command to allow the retrieval of a recipients public key prior to the transmission of a mail. This
>will enable the sender to encrypt the email content before the same is transmitted through the existing SMTP
>commands.
>

It also treats mail providers like Google and Comcast as "end users" which
seems quite wrong.

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.

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? 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.

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.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sat, 08 May 2021 12:27:19 -0400

--On Saturday, May 8, 2021 15:43 +0100 Jeremy Harris
<[email-masked]> wrote:

> On 08/05/2021 15:03,
> patrick.peisker=[email-masked] wrote:
>> In order to address this interoperability issue in a
>> standards centric approach, the proposal is the addition of a
>> new SMTP command to allow the retrieval of a recipients
>> public key prior to the transmission of a mail. This will
>> enable the sender to encrypt the email content before the
>> same is transmitted through the existing SMTP commands.
> 
> This requires the MUA to be a full MTA not just an MSA passing
> off outbound traffic to a real MTA,  Not the current usual
> architecture.
> 
> It also doesn't work with traditional-forwarding, I think,
> unless the forwarder decrypts and re-encrypts.

Noting that things very similar to this have been proposed
before, it also does not work with relays.  The problem as
really the same as with VRFY: (which could, in principle, easily
be extended to do this).  First, one need to be able to ask the
final recipient system whether an email address is valid and
deliverable and then get the key for it.  But much of the
community has already decided that the validity check itself is
a security and/or privacy violation and a bad idea, so VRFY is
not nearly as broadly supported as it was 20 or 30 years ago.  

Now, one could imagine a different way to do this.  One could
imagine a different kind of mail transaction and command
associated with GETK.   Unlike VRFY, which needs to expect a
reply equivalent to "don't have a clue" if the comment reaches a
relay that does not have an accurate list and profile of valid
addresses at the destination and willingness to give them out
(as well as the MUA problem Jeremy mentions) GETK would act more
like SOML: if it reaches a system that has the data, it provides
it and, if it doesn't, it relays to the next system in the MX
page.  That, of course, means that one would need to invent a
new type of message disposition format, might need to worry
about blowback prevention or the like, would need to discuss
whether one could issue GTKY commands during conventional mail
transaction (in which MAIL commands are also present), how many
of them could be issued in a session, etc.: lots of details to
be sorted out.  And I'd predict that getting MSAs and MTA
(including both relay and delivery configurations) to implement
it and convincing people to configure it would be a hard sell.
But it is probably possible.

FWIW, also note that ideas of putting user or mailbox names (not
just host names) into the DNS to support a variety of things has
been around since the early design of the DNS.. and that
proposals to do that to allow public key retrieval have been
around almost since there have been public keys.  Not much
traction there either --even though it would be lots less
complex than trying to extend SMTP to do it through relays-- and
probably for good reason.

I want to stress that I don't think this is a terrible idea,
especially if it were used to retrieve keys for S/MIME or PGP
use rather than inventing yet another mechanism.  I do see it as
rather difficult to get implemented and widely enough deployed
to be useful (see John Levine's note, which arrived after this
message was nearly finished and to which I will respond soon).
I would, however, think about looking at this a different way.
At least for PGP, there are widely available public key stores
from which an interested MUA could easily retrieve any keys that
happen to be there using LDAP and probably other mechanisms --
all less complicated than building something into SMTP.  The
main problem with those systems has been getting people to put
keys in there, especially keys that, instead of being
self-signed, are sufficiently more part of some web of trust
that one would want to use them.  That is slightly less of an
issue for encryption than it is for signatures but one needs to
be careful about what one believes -- and than opens up the
entire can of works with PKI arrangements.  Another problem is
that many of us use many more email addresses than we use keys,
some with so-called subaddresses arrangements and, to the best
of my knowledge, no one has sorted out the right arrangements
for LDAP, arrangements that don't rather seriously break SMTP
principles.  If I remember, this message will be signed, but the
key does not have "[email-masked] as one of the addresses on
it.  In some cases, that might be an advantage for a proposal
like the one you suggest -- in my case, the final delivery
server knows, or could easily know, how to short such things out
but, to use John's example, Google and Comcast probably don't.

In particular, you (Patrick) wrote:

> As the SMTP standard is widely adopted, the introduction of
> such a command could exponentially increase the adoption of
> more secure email communication. Alternative options such as
> the use of separate and dedicated key stores to solve this
> issue have not only be unsuccessful to drive higher security
> for email communication, but they also operate outside of the
> established standards and infrastructure deployed by email
> providers across the globe.

What I think you are missing is that SMTP implementations are
not required to implement any given extension.  Even if the IETF
decided to work out the details of "GETK" and require it, that
requirement would not mean much.  So I don't think you can
extrapolate from SMTP is widely deployed" to "this would be".  I
fear that, until there are major changes in attitudes and user
educations, it would be likely to go the way of those "alternate
solutions".

  best,
   john

---

From: John C Klensin <[email-masked]>
Date: Sat, 08 May 2021 12:53:26 -0400

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

- - --On Saturday, May 8, 2021 11:17 -0400 John Levine
<[email-masked]>
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.

> 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.

---

From: "John Levine" <[email-masked]>
Date: 8 May 2021 13:26:02 -0400

It appears that John C Klensin  <[email-masked]> said:
>been around since the early design of the DNS.

I'd forgotten about RFC 7929 which purports to put PGP keys
in the DNS.  It's fairly badly broken since mail and the DNS
have different ideas about name matching, but it doesn't matter
because nobody ever has used it.

>use rather than inventing yet another mechanism.

I think it's a terrible idea both because it puts the keys in the wrong
place and the reasons you gave, extensions are optional which means
not implemented.

>all less complicated than building something into SMTP. ...

Right.  This idea has failed plenty of times already.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 May 2021 12:09:18 -0700

> Right.  This idea has failed plenty of times already.

As I recall, at least one perceived problem with the dramatic difference 
in scale between querying for a host versus query for a user.

I recently noted that Shaken/Stir requires a cert per phone number, 
which seems a rather larger scale of real-world use than certs have 
otherwise gotten, to date.  Not sure how many orders of magnitude 
difference, but likely more than one.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 11 May 2021 13:48:20 +0200

On Sat 08/May/2021 19:26:02 +0200 John Levine wrote:
> in the DNS.  [...]

I'm not clear why a domain's MX would be the wrong place.  A similar idea is to 
store the keys at a domain's well-known place, so as to get them via https. 
The draft also includes a mail-based protocol to update the web key directory.

https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service

Best
Ale
--

---

From: "John Levine" <[email-masked]>
Date: 11 May 2021 14:55:42 -0400

It appears that Alessandro Vesely  <[email-masked]> said:
>I'm not clear why a domain's MX would be the wrong place.

Because you can't tell the user's relation to the domain.  Would you
want Google to be the authoritative source of keys for every gmail
user?  Apollo Global Management for every Yahoo and AOL user?

Personally, as a passive-aggressive mail system operator, the only keys
my MX would publish would be proxy ones that let my MTA decode the
mail and do spam and malware filtering.  If my users don't like that,
they can manage their own fripping keys.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Tue, 11 May 2021 23:47:52 -0400

--On Tuesday, May 11, 2021 14:55 -0400 John Levine
<[email-masked]> wrote:

>>> I think it's a terrible idea both because it puts the keys
>>> in the wrong place and the reasons you gave, extensions are
>>> optional which means not implemented.
>> 
> Because you can't tell the user's relation to the domain.
> Would you want Google to be the authoritative source of keys
> for every gmail user?  Apollo Global Management for every
> Yahoo and AOL user?

Well, if the keys were signed by entities I trusted, I wouldn't
be worried about what "authoritative source" means.  And if they
weren't, not only would I not like that, but it would probably
turn the whole idea into theater rather than security.   And, as
you know at least as well as I do, getting general-purpose keys
signed in a way that could be generally depended on has proven
to be a challenge.(to put it mildly).

And you didn't ask the question of why Google would want to go
into that business given that it would increase their
liabilities, not add significantly to what they already know
about gmail users or the ability to sell ads, and increase the
costs of a "free" service.  But perhaps I'm missing something.

> Personally, as a passive-aggressive mail system operator, the
> only keys my MX would publish would be proxy ones that let my
> MTA decode the mail and do spam and malware filtering.  If my
> users don't like that, they can manage their own fripping keys.

Yeah, something like that.
best,
   john

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 12 May 2021 12:09:28 +0200

On Wed 12/May/2021 05:47:52 +0200 John C Klensin wrote:
> --On Tuesday, May 11, 2021 14:55 -0400 John Levine wrote:
>>>> I think it's a terrible idea both because it puts the keys in the
>>>> wrong place and the reasons you gave, extensions are optional which
>>>> means not implemented. >>>
>> Because you can't tell the user's relation to the domain. Would you want
>> Google to be the authoritative source of keys for every gmail user?
>> Apollo Global Management for every Yahoo and AOL user?

At least, I'd expect Google to be aware that I have a mailbox at theirs, in 
case.  Different keyservers either treat email addresses as opaque tokens or 
need to periodically check whether the email address is still in use by the key 
holder.

Yes, freemail providers are the overwhelming majority, but there are also other 
mail sites.  And the need of an interoperable standard is mostly necessary for 
the latter ones.

> Well, if the keys were signed by entities I trusted, I wouldn't be worried
> about what "authoritative source" means.  And if they weren't, not only
> would I not like that, but it would probably turn the whole idea into
> theater rather than security.   And, as you know at least as well as I do,
> getting general-purpose keys signed in a way that could be generally
> depended on has proven to be a challenge.(to put it mildly).

There are different classes of mailbox providers.  Some have personal knowledge 
of their users, other accept anonymous subscription.  Some users trust their 
mailbox provider.  Some kind of provider can even sign the public keys of its 
users.

I don't think that distrust of one's provider is the only reason to apply 
end-to-end encryption.  Consider a message signed by [email-masked] 
whose key is authenticated by the company.  Isn't that a good employer-employee 
relationship?

>> MTA decode the mail and do spam and malware filtering.

I was talking about /public/ keys.

Best
Ale
--

---

From: "John R Levine" <[email-masked]>
Date: 12 May 2021 12:25:00 -0400

On Tue, 11 May 2021, John C Klensin wrote:
>>> I'm not clear why a domain's MX would be the wrong place. ..,

> turn the whole idea into theater rather than security.

Indeed.  But if the keys include signatures, it doesn't matter where they 
come from, so we're back to asking why nobody seems to use the key servers 
that already exist.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Wed, 12 May 2021 12:31:01 -0400

> I was talking about /public/ keys.

Right.  Your MX publishes a public key to which it has the corresponding
private key.  This is well understood technology - see any company that
intercepts https:// and re-encrypts the user-side traffic using their own keys.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 May 2021 09:46:08 -0700

> intercepts https:// and re-encrypts the user-side traffic using their own keys.

or DKIM.

d/

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 12 May 2021 18:57:26 +0200

On Wed 12/May/2021 18:46:08 +0200 Dave Crocker wrote:
>> private key.

It doesn't have to.  The mail-based update protocol for wkd[*], for example, is designed to keep the secret key secret.

>> This is well understood technology - see any company that intercepts
>> https:// and re-encrypts the user-side traffic using their own keys.> 
> or DKIM.

Neither case provides for end-to-end crypto.  (Hm... possibly except DKIM for postmaster to postmaster communication, deploying the binary key as OpenGPG.  Not an alluring technique.)

Best
Ale
-- 

[*] https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service#section-4

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 12 May 2021 19:04:05 +0200

On Wed 12/May/2021 18:25:00 +0200 John R Levine wrote:
>> be worried about what "authoritative source" means.
> 
> Indeed.  But if the keys include signatures, it doesn't matter where they come 
> from, so we're back to asking why nobody seems to use the key servers that 
> already exist.

Some people has been using those key servers.  However, they're vulnerable to 
pgp-poisoning attacks[*].

Best
Ale
-- 

[*] https://github.com/skeeto/pgp-poisoner

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 May 2021 13:48:55 -0400

--On Wednesday, May 12, 2021 18:57 +0200 Alessandro Vesely
<[email-masked]> wrote:

>...

>>> This is well understood technology - see any company that
>>> intercepts https:// and re-encrypts the user-side traffic
>>> using their own keys.> 
>> or DKIM.

> Neither case provides for end-to-end crypto.  (Hm... possibly
> except DKIM for postmaster to postmaster communication,
> deploying the binary key as OpenGPG.  Not an alluring
> technique.)

And, getting back to the point that John Levine, myself, and
others have been trying to make, there is a world (or at least
several orders of magnitude) of difference between keys
associated with hosts (mail servers, firewall gateways, web
sites, etc.) and those associated with individual users or
mailbox names.

best,
   john

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 May 2021 14:13:19 -0400

--On Wednesday, May 12, 2021 19:04 +0200 Alessandro Vesely
<[email-masked]> wrote:

>... 
>> Indeed.  But if the keys include signatures, it doesn't
>> matter where they come  from, so we're back to asking why
>> nobody seems to use the key servers that  already exist.
> 
> Some people has been using those key servers.  However,
> they're vulnerable to pgp-poisoning attacks[*].
>...

We are getting fairly far off-topic, but ...

There is an extremely straightforward way to resist such
attacks, which is to accept key updates only from the
authenticated key owner or, _maybe_ from one of the existing
signatories whose key is already in the repository.  There are
issues there too, but most of them come down to something John
Levine pointed out earlier in the thread (and that has been
known since the 1990s), which is that PGP's web of trust concept
does not scale very well.  I can think of another defense too,
but, again, we are getting fairly far off-topic.

But, Ale, it seems to me that almost everyone but you is saying
things that ultimately lead to the same place: either that it
would not be a good idea to try to build this into SMTP or that,
we we did, it either wouldn't work or there would not be enough
uptake and deployment to make it useful.  That does not
necessarily mean that we are right and you are wrong, but it
does suggest that this thread is nearing the end of its useful
life.

best,
    john

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 May 2021 11:44:34 -0700

On 5/12/2021 9:57 AM, Alessandro Vesely wrote:
> 
> Neither case provides for end-to-end crypto.  (Hm... possibly except 
> DKIM for postmaster to postmaster communication, deploying the binary 
> key as OpenGPG.  Not an alluring technique.)

DKIM doesn't use encryption, but it does do signing, which is a crypto 
function.

More simply: the thing that is published in a DKIM record is a public key.

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 12 May 2021 11:46:30 -0700

On 5/12/2021 10:04 AM, Alessandro Vesely wrote:
>> Indeed.  But if the keys include signatures, it doesn't matter where 
>> they come from, so we're back to asking why nobody seems to use the 
>> key servers that already exist.
> 
> Some people has been using those key servers.  However, they're 
> vulnerable to pgp-poisoning attacks[*].

The 'nobody' terminology is apt, in terms of operational statistics. 
The number of users is statistically insignificant, especially over a 
period of decades.

"Too few to matter" would be the alternative wording.

d/

---

From: Ned Freed <[email-masked]>
Date: Wed, 12 May 2021 17:45:50 -0700 (PDT)

Responding late to this thread... I wanted to note that
the need to store and manage lots of keys can be addressed
through the use of identity based encryption, which in effect
reduces the number of keys you need to store from one per
user to 1.

RFCs 5091 and 6508 cover specific IBE schemes, however, for
introductory material you'll need to look elsewhere.

I also note that there can still be advantages to having
a per-user lookup (either in or out of band) for the user's
public key - a lookup has the potential to tell you that
a given user is actually capable of receiving encrypted
mail. 

All that said, making server side implementation easier
does nothing to solve the real problem: All available
evidence says that there won't be sufficient uptake to
matter.

				Ned

> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 May 2021 21:45:52 -0400

> introductory material you'll need to look elsewhere.

Good point, at least in theory (see below).  That would also
eliminate the need for per-user entries if using the DNS.

> a given user is actually capable of receiving encrypted

Indeed.

> evidence says that there won't be sufficient uptake to

And that is the practice that goes with the theory.  We really
don't have a shortage of mechanisms for locating and retrieving
keys. Unless something changes the conditions that have
frustrated deployment and use, there is no evidence that adding
another mechanism would make enough difference to be worth the
effort (and, as John Levine pointed out, statistically probably
no difference at all).   I can imagine scenarios that would
change the situation, but I don't expect any of them soon and
none of them would cause the presence or absence of one more key
location and retrieval mechanism to be an impediment.

    john

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 13 May 2021 09:06:37 +0200

On Wed 12/May/2021 20:13:19 +0200 John C Klensin wrote:
> 
> But, Ale, it seems to me that almost everyone but you is saying things that
> ultimately lead to the same place: either that it would not be a good idea
> to try to build this into SMTP or that, we we did, it either wouldn't work
> or there would not be enough uptake and deployment to make it useful.

No, I wouldn't support building public key retrieval into SMTP.  I just hold 
that, since public keys are linked to email addresses which in turn are linked 
to Internet domains, domain servers are the right place to store public keys.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 13 May 2021 09:20:09 +0200

On Wed 12/May/2021 20:44:34 +0200 Dave Crocker wrote:
>> Neither case provides for end-to-end crypto.  (Hm... possibly except DKIM for 
>> postmaster to postmaster communication, deploying the binary key as OpenGPG.  
>> Not an alluring technique.)
> 
> DKIM doesn't use encryption, but it does do signing, which is a crypto function.
> 

Right.  Anyway, if I encrypted something using your DKIM public key, you could 
easily decrypt it using the private key.  (There's a script by the Monkeysphere 
Project, pem2openpgp, which can transform a DKIM private key into an OpenPGP 
key for signing.  A silly exercise.)

Best
Ale
--

---

From: Richard Clayton <[email-masked]>
Date: Thu, 13 May 2021 10:33:09 +0100

In message <[email-masked]>, Alessandro
Vesely <[email-masked]> writes

>easily decrypt it using the private key.

please don't do that -- from a legal standpoint when resisting attempts
by Law Enforcement to request private keys, it puts you on very strong
ground to argue that a key has only ever been used for authentication
rather than encryption

also, by using the same key for different purposes you increase the risk
of chosen protocol attacks and other bad things happening, which is why
expert advice is to always to avoid loading the gun, even if you are
promising never to point it anywhere near your lower extremities

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: Matthias Leisi <[email-masked]>
Date: Fri, 14 May 2021 09:22:50 +0200

> Am 13.05.2021 um 03:45 schrieb John C Klensin <[email-masked]>:

> location and retrieval mechanism to be an impediment.

Speaking from practice (offering encrypted mail services to local clients), the following are positive drivers for end-to-end encryption:

1) Network effects: community of users / industry / geographical area. In our case: local lawyers driven by compliance have considerable uptake of encryption. 

2) Ease-of-use: Non-technical people have little patience to care about the details of encryption, key handling and similar non-productive use of their time. In our case: a server-based solution greatly simplifies these things. Yes, this breaks the end-to-end mantra, but it blends in better with other compliance requirements (eg archiving). Additional improvement: simple, rule-based encryption. If the „Confidential“ flag is ticked or a specific tag is in the subject, require encryption. 

3) Be pragmatic. In our case: solutions that „know“ each other (from the same vendor) share a list of trusted domain-based certificates, and always sign/encrypt amongst themselves transparently. This protects against interceptions or falsifications in transit, regardless of the number of intermediate hops. Nothing more, but nothing less. And it lays the ground for improvements over time.

Drivers that hinder adoption:

1) Lack of standard to share & trust domain-based certificates. Standardising on a Public Key Lookup mechanism could be very helpful.

2) Access to and handling of certificates: We miss a „Let’s Encrypt for E-Mail“. And the MUAs are woefully inadequate to request, renew etc keys and certificates. In our service, we handle the keys and certificates server-side through a managed PKI service, but adoption would be _much_ better if the MUAs would do a better job.

3) Bureaucracy, organizational inertia: We found that many organizations have some encryption capability, but strictly limit its use. Funky PDF-based processes are required to get it to work for very narrow sets of users and use cases. Some best practice document may help those organizations to better adopt what they already have. 

A data point: while we offer both PGP and S/MIME-based service, we have exactly 0% adoption of PGP (even though it is slightly cheaper due to the lack of certificate cost).

— Matthias

---

From: John C Klensin <[email-masked]>
Date: Fri, 14 May 2021 09:52:42 -0400

Matthias,

I found this very helpful ... and quite consistent with my
experience and predictions from very different contexts.  I
think we need to be aware of the tempting target presented by an
organizational server that holds and manages private keys but,
in the grand scheme of things, that may be less problematic and
risky than, e.g., hop by hop encryption with messages in clear
on poorly protected relay boxes.

thanks,
   john

--On Friday, May 14, 2021 09:22 +0200 Matthias Leisi
<[email-masked]> wrote:

>> don't have a shortage of mechanisms for locating and
>> retrieving keys. Unless something changes the conditions that
>> have frustrated deployment and use, there is no evidence that
>> adding another mechanism would make enough difference to be
>> worth the effort (and, as John Levine pointed out,
>> statistically probably no difference at all).   I can imagine
>> scenarios that would change the situation, but I don't expect
>> any of them soon and none of them would cause the presence or
>> absence of one more key location and retrieval mechanism to
>> be an impediment.
> 
> Speaking from practice (offering encrypted mail services to
> local clients), the following are positive drivers for
> end-to-end encryption:
> 
> 1) Network effects: community of users / industry /
> geographical area. In our case: local lawyers driven by
> compliance have considerable uptake of encryption. 
> 
> 2) Ease-of-use: Non-technical people have little patience to
> care about the details of encryption, key handling and similar
> non-productive use of their time. In our case: a server-based
> solution greatly simplifies these things. Yes, this breaks the
> end-to-end mantra, but it blends in better with other
> compliance requirements (eg archiving). Additional
> improvement: simple, rule-based encryption. If the
> „Confidential" flag is ticked or a specific tag is in the
> subject, require encryption. 
> 
> 3) Be pragmatic. In our case: solutions that „know" each
> other (from the same vendor) share a list of trusted
> domain-based certificates, and always sign/encrypt amongst
> themselves transparently. This protects against interceptions
> or falsifications in transit, regardless of the number of
> intermediate hops. Nothing more, but nothing less. And it lays
> the ground for improvements over time.
> 
> 1) Lack of standard to share & trust domain-based
> certificates. Standardising on a Public Key Lookup mechanism
> could be very helpful.
> 
> 2) Access to and handling of certificates: We miss a
> „Let's Encrypt for E-Mail". And the MUAs are woefully
> inadequate to request, renew etc keys and certificates. In our
> service, we handle the keys and certificates server-side
> through a managed PKI service, but adoption would be _much_
> better if the MUAs would do a better job.
> 
> 3) Bureaucracy, organizational inertia: We found that many
> organizations have some encryption capability, but strictly
> limit its use. Funky PDF-based processes are required to get
> it to work for very narrow sets of users and use cases. Some
> best practice document may help those organizations to better
> adopt what they already have. 
> 
> A data point: while we offer both PGP and S/MIME-based
> service, we have exactly 0% adoption of PGP (even though it is
> slightly cheaper due to the lack of certificate cost).
> 
> — Matthias
> 
> 
>

---

From: "John Levine" <[email-masked]>
Date: 14 May 2021 15:15:06 -0400

>on poorly protected relay boxes.

Agreed, it's a nice summary.

I have noted there is currently no way to get a single S/MIME certificate
without paying an unreasonable amount of money.  A few CAs used to issue them for free,
but no more.  Some sort of LE for S/MIME would be much more likely make a difference
than yet another kind of rarely available key server.

---

From: Gene Hightower <[email-masked]>
Date: Fri, 14 May 2021 12:45:25 -0700

Another approach is pretty Easy privacy (p≡p)
<https://en.wikipedia.org/wiki/Pretty_Easy_privacy>

It needs to be integrated with the MUA ("email client") but it's TOFU
and dead simple in operation.

Fingers crossed for this attempt to solve the key exchange problem.

---

From: Gene Hightower <[email-masked]>
Date: Fri, 14 May 2021 12:50:41 -0700

> Another approach is pretty Easy privacy (p≡p)

Or maybe autocrypt might take off?
<https://en.wikipedia.org/wiki/Autocrypt>

Something, anything...

---

From: "John Levine" <[email-masked]>
Date: 14 May 2021 16:14:32 -0400

It appears that Gene Hightower  <[email-masked]> said:
>-=-=-=-=-=-
>-=-=-=-=-=-

S/MIME is built into every desktop MUA and most mobile MUAs.  Once you get
the key installed, it's also TOFU and fairly automatic.

Given that PEP has been around for five years and this is the first I've heard
of it, I don't think that yet another crypto system is going to solve anything.

R's,
John

---

From: Gene Hightower <[email-masked]>
Date: Fri, 14 May 2021 13:19:50 -0700

> the key installed, it's also TOFU and fairly automatic.

The problem here seems to be getting a cert.

> of it, I don't think that yet another crypto system is going to solve anything.

Well, it's PGP under the hood.

(I'm not an expert on any of these systems, so please anybody correct me
if I'm wrong)

---

From: "John R Levine" <[email-masked]>
Date: 14 May 2021 16:28:09 -0400

> The problem here seems to be getting a cert.

Right, hence my note about LE for S/MIME.

Regards,

---

From: John C Klensin <[email-masked]>
Date: Fri, 14 May 2021 16:57:11 -0400

--On Friday, May 14, 2021 15:15 -0400 John Levine
<[email-masked]> wrote:

>> think we need to be aware of the tempting target presented by
>> an organizational server that holds and manages private keys
>> but, in the grand scheme of things, that may be less
>> problematic and risky than, e.g., hop by hop encryption with
>> messages in clear on poorly protected relay boxes.
> 
> I have noted there is currently no way to get a single S/MIME
> certificate without paying an unreasonable amount of money.  A
> few CAs used to issue them for free, but no more. 

http://www.cacert.org/ and, in particular,
http://wiki.cacert.org/EmailCertificates  ??

Of course, when last I checked, none of the usual browser
vendors recognize their root cert, so working with their
certificates is probably not an plausible exercise for the
casual user.  I've asked "why not" a few times but I mostly
don't get answers and those I do get sound a lot like "follow
the money".

> Some sort
> of LE for S/MIME would be much more likely make a difference

Yep.

    john

---

From: Matthias Leisi <[email-masked]>
Date: Sat, 15 May 2021 08:19:24 +0200

> Am 14.05.2021 um 22:28 schrieb John R Levine <[email-masked]>:

> Right, hence my note about LE for S/MIME.

LE is quite clear they won‘t issue certs for S/MIME: https://community.letsencrypt.org/t/s-mime-certificates/153/2

I‘m not familiar with the internal thinking at LE on this topic, but I guess one strong argument is the complexity of regularly renewing the certificates, which is one or two orders of magnitude worse than for server certificates. It‘s actually even worse, because MUAs (or „security gateways“) need to „learn“ new certs regularly, even if communication is less frequent than the renewal interval of the certificates.

The other argument may be that people will sometimes lose their private key (been there myself, I still have part of my mail archive from the late 1990ies encrypted with a long lost PGP key…).

Still, these and similar issues can be technically solved (or accepted as a trade-off). 

How can ietf-smtp help in paving the way for such an adoption?

— Matthias

---

From: "John Levine" <[email-masked]>
Date: 15 May 2021 12:59:43 -0400

That thread ended three years ago.  Last month, the IETF published RFC 8823 which extends the ACME protocol
to issue S/MIME certificates.  I doubt that Alexey wrote it purely as an hypothetical exercise.

>How can ietf-smtp help in paving the way for such an adoption?

Honestly, by not wasting time with diversions that are unlikely to do anything useful.

Pretty much every MUA other than webmail already has S/MIME support.  If a few of them let their users get
certs with one click, it might make a difference.

R's,
John

---

From: [email-masked]
Date: Mon, 24 May 2021 16:32:36 +0000

Thank you all for the feedback and additional pointers. I will research alternative ways to improve the adoption of encrypted (email) communication.

Best

Patrick

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Saturday, May 15, 2021 10:29 PM, John Levine <[email-masked]> wrote:

> It appears that Matthias Leisi [email-masked] said:
>
> > -=-=-=-=-=-
> >
> > > Am 14.05.2021 um 22:28 schrieb John R Levine [email-masked]:
> >