Re: Public Key Look Up

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

> 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
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-smtp