1 |
On Fri, Aug 21, 2020 at 3:37 PM Grant Taylor |
2 |
<gtaylor@×××××××××××××××××××××.net> wrote: |
3 |
> |
4 |
> On 8/21/20 6:37 AM, Rich Freeman wrote: |
5 |
> > This stuff can be interesting to discuss, but email is SO entrenched |
6 |
> > that I don't see any of this changing because of all the legacy issues. |
7 |
> > You would need to offer something that is both easier and better to |
8 |
> > use to such a degree that people are willing to change. |
9 |
> |
10 |
> "something that is /both/ *easier* and *better*". |
11 |
> |
12 |
> That's a VERY tall bar to clear. |
13 |
|
14 |
Hence I'm going to basically reply to only a few lines of your email - |
15 |
this isn't going to go anywhere so I really don't want to get into an |
16 |
endless argument about why people use webservices/etc. |
17 |
|
18 |
> What does JSON / XML / etc. on top of HTTP(S) provide that SMTP doesn't |
19 |
> provide? |
20 |
|
21 |
It is what just about every other modern application in existence |
22 |
uses. I'm sure there are hundreds of articles on the reasons for this |
23 |
that are far better than anything I'd come up with here. |
24 |
|
25 |
> > ... use more standard libraries/etc. |
26 |
> |
27 |
> There are many libraries to interface with SMTP. |
28 |
|
29 |
And they don't work for anything OTHER than SMTP. |
30 |
|
31 |
A library for JSON/webservices/whatever works for half the |
32 |
applications being written today. |
33 |
|
34 |
|
35 |
> |
36 |
> Stop focusing on HTTP(S) <any version thereof> for a few minutes. |
37 |
> |
38 |
> If you were to create a new protocol from the ground up, why would you |
39 |
> introduce additional layers into the application stack — which represent |
40 |
> additional dependencies and complications — if you didn't have to? |
41 |
> |
42 |
> Not everything is a web server. Not everything can benefit from being |
43 |
> forced through a web server. |
44 |
|
45 |
This is simple. This is how just about EVERYBODY does it these days. |
46 |
http works as a transport mechanism. And obviously when I say http I |
47 |
mean http/https with the latter being preferred. That is the beauty |
48 |
of standards like this - somebody else figured out SSL on top of HTTP |
49 |
so we don't need an email-specific reimplementation of that. |
50 |
|
51 |
I mean, why use TCP? Why not use something more tailored to email? |
52 |
TCP probably has a dozen optional features that nobody uses with |
53 |
email, so why implement all that just to send email? |
54 |
|
55 |
The answer is that it makes WAY more sense to recycle a standard |
56 |
protocol than to invent one. If SMTP didn't exist, and we needed a |
57 |
way to post a bunch of data to a remote server, you'd use HTTP, |
58 |
because it already works. |
59 |
|
60 |
> > Most of the benefits only accrue if you adopt PKI as well, which is |
61 |
> > a problem that is hard to scale out to the masses. |
62 |
> |
63 |
> PKI is relatively easy to scale. (For a given value.) Hence the |
64 |
> thriving CA industry. |
65 |
> |
66 |
> Doing so in a trust worthy manner is the problem. Especially if you |
67 |
> want to avoid a single point of control / failure / GEO political / etc. |
68 |
|
69 |
It isn't just the trust problem. It is also the ease of use problem. |
70 |
|
71 |
Let's assume you trust all the CAs out there. Why isn't anybody using |
72 |
SSL for email? It is built into half the email clients out there. |
73 |
The problem is that exchanging certificates at an individual level is |
74 |
hard. |
75 |
|
76 |
Oh, for an organization with an IT department it isn't a problem. The |
77 |
IT department can just issue a certificate to everybody, generating |
78 |
keys for them. Then it can stick all the certs in some kind of |
79 |
directory that their email clients all use. |
80 |
|
81 |
Getting your cousin to use SSL certs for their email is a whole |
82 |
different matter. Heck, just using it between two different |
83 |
companies, both supported by professional IT depts, is a pain. You |
84 |
could use TLS for the transport itself and have the email servers |
85 |
configured to only use TLS for those domains, but actually doing E2E |
86 |
encryption is hard with email because there aren't a lot of standards |
87 |
for key exchange across unrelated orgs. |
88 |
|
89 |
> If we throw all the trusted CAs out the window, how do you /bootstrap/ |
90 |
> encrypted communications? - My personal opinion is DNS. |
91 |
> |
92 |
|
93 |
DNSSEC is: |
94 |
|
95 |
1. Still poorly supported even where it makes sense. |
96 |
2. A great hypothetical solution for the 0.002% of email users who |
97 |
own a domain name, like you and me. |
98 |
|
99 |
-- |
100 |
Rich |