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