1 |
On 8/21/20 5:58 PM, Rich Freeman wrote: |
2 |
> It is what just about every other modern application in existence uses. |
3 |
|
4 |
VoIP does not. |
5 |
|
6 |
No RDBMSs that I'm aware of use it as their primary protocol. (Some may |
7 |
be able to use HTTP(S) as an alternative.) |
8 |
|
9 |
Outlook to Exchange does (did?) not use it. It does have a sub-optimal |
10 |
RPC-over-HTTP(S) option for things like mobile clients. But you still |
11 |
get much better service using native non-HTTP(S) protocols. |
12 |
|
13 |
I'm not aware of any self hosted enterprise grade remote desktop |
14 |
solution that uses HTTP(S) as it's native transport. |
15 |
|
16 |
Just because it's possible to force something to use HTTP(S) does not |
17 |
mean that it's a good idea to do so. |
18 |
|
19 |
> I'm sure there are hundreds of articles on the reasons for this that |
20 |
> are far better than anything I'd come up with here. |
21 |
|
22 |
Probably. |
23 |
|
24 |
> And they don't work for anything OTHER than SMTP. |
25 |
|
26 |
There are /other/ libraries that work for /other/ things. |
27 |
|
28 |
Having a general thing that can be abused for almost all things is |
29 |
seldom, if ever, the optimal way to achieve the goal. |
30 |
|
31 |
> A library for JSON/webservices/whatever works for half the applications |
32 |
> being written today. |
33 |
|
34 |
I choose to believe that even that 50% is significantly sub-optimal and |
35 |
that they have been pressed into that role for questionable reasons. |
36 |
|
37 |
> This is simple. This is how just about EVERYBODY does it these days. |
38 |
|
39 |
I disagree. |
40 |
|
41 |
Yes, a lot of people do. But I think it's still a far cry from "just |
42 |
about everybody". |
43 |
|
44 |
> http works as a transport mechanism. |
45 |
|
46 |
Simply working is not always enough. Dial up modems "worked" in that |
47 |
data was transferred between two endpoints. Yet we aren't using them today. |
48 |
|
49 |
Frequently, we want optimal or at least the best solution that we can get. |
50 |
|
51 |
> That is the beauty of standards like this - somebody else figured out |
52 |
> SSL on top of HTTP so we don't need an email-specific reimplementation |
53 |
> of that. |
54 |
|
55 |
I think that you are closer than you realize or may be comfortable with. |
56 |
|
57 |
"somebody else figured out" meaning that "someone else has already done |
58 |
the work or the hard part". Meaning that it's possible to ride people's |
59 |
coat tails. |
60 |
|
61 |
HTTP(S) as a protocol has some very specific semantics that make it far |
62 |
from ideal for many things. Things like the server initiating traffic |
63 |
to clients. Some, if not many, of these semantics impose artificial |
64 |
limitations on services. |
65 |
|
66 |
> I mean, why use TCP? |
67 |
|
68 |
For starters, TCP ensures that your data arrives at the other end (or |
69 |
notifies you if it doesn't), that it's in order, and that it's not |
70 |
duplicated. |
71 |
|
72 |
There are multiple other protocols that you can use. UDP is a prominent |
73 |
one. |
74 |
|
75 |
> Why not use something more tailored to email? |
76 |
|
77 |
Now you're comparing an application layer protocol (email(SMTP)) to a |
78 |
network transport protocol (TCP / UDP / etc.). |
79 |
|
80 |
What transport layer protocol would you suggest using? |
81 |
|
82 |
Be careful to trace higher layer abstraction protocols, e.g. QUIC, back |
83 |
down to the transport layer protocol (UDP in QUIC's case). |
84 |
|
85 |
> TCP probably has a dozen optional features that nobody uses with email, |
86 |
> so why implement all that just to send email? |
87 |
|
88 |
What contemporary operating system does not have a TCP/IP stack already? |
89 |
|
90 |
How are applications on said operating system speaking traditional / |
91 |
non-QUIC based HTTP(S) /without/ TCP? |
92 |
|
93 |
Even exclusively relying on QUIC still uses UDP. |
94 |
|
95 |
> The answer is that it makes WAY more sense to recycle a standard |
96 |
> protocol than to invent one. |
97 |
|
98 |
You're still inventing a protocol. It's just at a higher layer. You |
99 |
still have to have some way / method / rules / dialect, more commonly |
100 |
known as a protocol, on whatever communications transport you use. |
101 |
|
102 |
Even your web based application needs to know how to communicate |
103 |
different things about what it's doing. Is it specifying the sender or |
104 |
the recipient or the subject or something else. Protocols are what |
105 |
define that. They are going to exist. It's just a question of where |
106 |
they exist. |
107 |
|
108 |
You're still inventing a protocol. |
109 |
|
110 |
Do you want your protocol to run on top of a taller more complex stack |
111 |
of dependencies? Or would you prefer a shorter simpler stack of |
112 |
dependencies? |
113 |
|
114 |
You're still inventing a protocol. You're just choosing where to put |
115 |
it. And you seem to be in favor of the taller more complex stack. |
116 |
Conversely I am in favor of the shorter simpler stack. |
117 |
|
118 |
> If SMTP didn't exist, and we needed a way to post a bunch of data to |
119 |
> a remote server, you'd use HTTP, because it already works. |
120 |
|
121 |
No. /I/ would not. |
122 |
|
123 |
HTTP(S) is inherently good at /retrieving/ data. We have used and |
124 |
abused HTTP(S) to make it push data. |
125 |
|
126 |
Depending what the data was and the interactive nature of it, I would |
127 |
consider a bulk file transfer protocol FTPS / SFTP / SCP or even NAS |
128 |
protocols. Things that are well understood and well tested. |
129 |
|
130 |
If I had some reason that they couldn't do what I needed or as |
131 |
efficiently as I needed, I would develop my own protocol. I would |
132 |
certainly do it on top of a transport protocol that ensured my data |
133 |
arrived (or it told me), in order, and not duplicated. |
134 |
|
135 |
I could develop my own protocol that allowed me to start from a clean |
136 |
slate and did not impose rules on what I could say or how I would say |
137 |
it. HTTP(S) starts with impositions of what you can say and how you can |
138 |
say it. |
139 |
|
140 |
If you are creating something completely green field that rides entirely |
141 |
on top of HTTP(S), you have issues with bidirectionality and / or |
142 |
latency and / or request reply correlation by how the HTTP protocol |
143 |
operates. |
144 |
|
145 |
TCP is so easy to use that simple Bash shell scripts can utilize it by |
146 |
opening files. |
147 |
|
148 |
TCP already works too. And TCP works without the additional overhead of |
149 |
HTTP stack on top of it. |
150 |
|
151 |
> It isn't just the trust problem. It is also the ease of use problem. |
152 |
|
153 |
I believe that the trust part of the problem is significantly more |
154 |
difficult than the ease of use part of the problem. |
155 |
|
156 |
> Let's assume you trust all the CAs out there. Why isn't anybody using |
157 |
> SSL for email? |
158 |
|
159 |
My personal opinion is that laziness and / or ignorance are the two |
160 |
biggest impediments. |
161 |
|
162 |
> It is built into half the email clients out there. |
163 |
|
164 |
I suspect that it's significantly more than half. I would speculate |
165 |
that it's more like > 90% of the mainstream email clients support |
166 |
encrypted communications channels; STARTTLS / SMTPS / IMAPS / POP3S / LDAPS. |
167 |
|
168 |
I speculate that all contemporary desktop email clients support at leat |
169 |
one form of encrypted message; S/MIME and / or PGP. |
170 |
|
171 |
Mobile clients may be more problematic. I know that Apple's Mail.app on |
172 |
iOS has supported S/MIME for as long as I've been using it, 10+ years. |
173 |
I don't know about the Android ecosystem. I would be shocked if there |
174 |
wasn't an email client that supported S/MIME. PGP may be more spotty. |
175 |
|
176 |
> The problem is that exchanging certificates at an individual level |
177 |
> is hard. |
178 |
|
179 |
No it is not. Not with a decent S/MIME implementation. |
180 |
|
181 |
I send someone a /signed/ message, and their reputable MUA learns my |
182 |
public key from my signature. (With requisite PKI/CA signing my keys.) |
183 |
|
184 |
Then when that person sends me a message, their reputable MUA will |
185 |
automatically encrypt messages to me using my public key. |
186 |
|
187 |
I can even learn their public key from the signature that they apply to |
188 |
the message that they encrypt to me. |
189 |
|
190 |
This is, or can be, almost completely transparent to end users. The |
191 |
only non-transparent part of of actual day-to-day use of S/MIME is the |
192 |
occasional "Would you like to use $SENDER's public key when |
193 |
communicating with them in the future?" type pop-up. Thunderbird with |
194 |
one add-on streamlines even that. |
195 |
|
196 |
Even installing the certificate is not any more difficult than original |
197 |
email account configuration. Admittedly it needs to happen again at |
198 |
certificate renewal time. So there is some room for improvement here. |
199 |
But even this is not a high bar. I don't believe this is a barrier to |
200 |
adoption. |
201 |
|
202 |
The most difficult (read: annoying) part of S/MIME is acquiring the |
203 |
S/MIME certificate. Even that's not unduly difficult. |
204 |
|
205 |
> Oh, for an organization with an IT department it isn't a problem. |
206 |
> The IT department can just issue a certificate to everybody, |
207 |
> generating keys for them. Then it can stick all the certs in some |
208 |
> kind of directory that their email clients all use. |
209 |
|
210 |
Doing anything with S/MIME (or PGP) at scale like you would as an |
211 |
individual is obviously untenable. But there are other options that |
212 |
help with businesses. It's possible to acquire a certificate that will |
213 |
allow you to sign other certificates. (It don't think it's a |
214 |
code-signing-certificate, but rather something quite similar.) |
215 |
|
216 |
> Getting your cousin to use SSL certs for their email is a whole |
217 |
> different matter. |
218 |
|
219 |
This is where the aforementioned "ignorance" comes in. I don't mean |
220 |
anything against your cousin, or anybody else for that matter. But the |
221 |
simple lack of simple understanding of what it is, why it's important, |
222 |
or how to do it is, in my humble opinion, the BIGGEST impediment to this. |
223 |
|
224 |
I mean "ignorance" in the way that most 3-5 year old kids are ignorant |
225 |
about how to read. They simply have not been exposed to or learned how |
226 |
to do it yet. There is no malicious intent. |
227 |
|
228 |
> Heck, just using it between two different companies, both supported by |
229 |
> professional IT depts, is a pain. |
230 |
|
231 |
I see no reason for it to be a pain. Can someone acquire the |
232 |
certificate(s) on the employees behalf? Can someone install them in the |
233 |
employees email client? |
234 |
|
235 |
Thunderbird with one simple add-on will automatically sign messages by |
236 |
default. |
237 |
|
238 |
As previously stated, sending a signed message contains sufficient |
239 |
information to boot strap S/MIME. |
240 |
|
241 |
The same add-on will automatically encrypt message to recipients that |
242 |
Thunderbird has seen a (current) public key from. |
243 |
|
244 |
So the end user simply needs to open Thunderbird and send an email. |
245 |
Which I'm fairly sure that there are hundreds of thousands of people |
246 |
doing already. |
247 |
|
248 |
So, I'm back to ignorance and laziness. Some of the ignorance is out of |
249 |
laziness and may be hedging on malicious complacency. |
250 |
|
251 |
Businesses /can/ make encryption trivial to use. Debian made it trivial |
252 |
to do so when I signed up for something. The portal that I used had an |
253 |
option to upload my public key. Uploading my public key is all that was |
254 |
required to receive S/MIME (or PGP) encrypted email from them. |
255 |
|
256 |
It is possible to make end-to-end encrypted email much less of an |
257 |
affront than it is or worse, what many people seemingly believe that it is. |
258 |
|
259 |
So, again, back to ignorance and / or laziness. |
260 |
|
261 |
> You could use TLS for the transport itself... |
262 |
|
263 |
Yes. |
264 |
|
265 |
This is and has been best practice for a decade or more. |
266 |
|
267 |
> ... have the email servers configured to only use TLS for those domains, |
268 |
|
269 |
This is currently a manual process. |
270 |
|
271 |
I would like to see some more automation around this. |
272 |
|
273 |
I believe there is some work effort with DNS-based Authentication of |
274 |
Named Entities (DANE) -and- MTA support to dynamically learn about and |
275 |
enforce TLS requirement. |
276 |
|
277 |
> but actually doing E2E encryption is hard with email because there |
278 |
> aren't a lot of standards for key exchange across unrelated orgs. |
279 |
|
280 |
S/MIME is self bootstraping. Signed emails, which can be sent to |
281 |
anyone, provide the sender's public key. There is no need for any |
282 |
external involvement. MUAs can completely handle this. |
283 |
|
284 |
> DNSSEC is: |
285 |
> |
286 |
> 1. Still poorly supported even where it makes sense. |
287 |
|
288 |
Yet another example of ignorance and / or laziness. |
289 |
|
290 |
I have found DNSSEC to be relatively easy to implement, and trivial to |
291 |
enable on my recursive resolvers. |
292 |
|
293 |
The ignorance portion is relatively easy to resolve if people want to. |
294 |
I highly recommend DNSSEC Mastery by Michael W. Lucas. That $20 (?) |
295 |
book and moderate amounts of motivation is all anybody that wants to |
296 |
implement DNSSEC /needs/. |
297 |
|
298 |
> 2. A great hypothetical solution for the 0.002% of email users who |
299 |
> own a domain name, like you and me. |
300 |
|
301 |
DNSSEC can be used for FAR more than just email domains. |
302 |
|
303 |
|
304 |
|
305 |
-- |
306 |
Grant. . . . |
307 |
unix || die |