--On Saturday, May 8, 2021 15:43 +0100 Jeremy Harris
<jgh(_at_)wizmail(_dot_)org> wrote:
On 08/05/2021 15:03,
patrick.peisker=40protonmail(_dot_)com(_at_)dmarc(_dot_)ietf(_dot_)org 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 "john-ietf(_at_)jck(_dot_)com 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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp