ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Public Key Look Up

2021-05-14 08:53:26
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
<matthias(_at_)leisi(_dot_)net> wrote:



Am 13.05.2021 um 03:45 schrieb John C Klensin
<john-ietf(_at_)jck(_dot_)com>:

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.

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



_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp