ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Public Key Look Up

2021-05-14 02:24:29


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

<Prev in Thread] Current Thread [Next in Thread>