On 2022-08-03 at 17:32:56 UTC-0400 (Wed, 03 Aug 2022 16:32:56 -0500)
Jarland Donnell via mailop <jarl...@mxroute.com>
is rumored to have said:
Firefox does not speak MTA, so you are talking about a completely
different problem. MTA is oportunistic TLS, web is required TLS.
Are equivalencies a bad thing though?
Only if you are saying things like 2+2=5, as in this case.
I'm talking about a general acceptance of the idea that a user should
not be given a false sense of security by being presented with
confirmation of a secure connection when it isn't secure.
A generic "confirmation of a secure connection" is not a part of any
MTA-MTA interaction.
Both the client and server *negotiate* security mechanisms to a common
ground of overall TLS version and ciphersuite. They AGREE on the
specific details of their security. And in any case, a TLSv1.0 session
using a good ciphersuite is no less secure for SMTP than a TLSv1.3
session using the same ciphersuite.
I shouldn't have to hold back from using similar situations in
illustrations simply because they're not a 1:1 match in irrelevant
ways.
The fact that SMTP is supposed to fall back to plaintext automatically
when STARTTLS fails is entirely relevant to whether you allow TLS
versions that are not inherently unsafe when used with SMTP.
The relevancy as pointed out in my words remains, stripping end users
from any connection to the technical details of a mail server is to be
completely ignorant of the exceptional growth of individual mail
server administrators who need guidance and rely on a sane industry to
perform sane activities around them.
Oh... I'm so sorry to have to break it to you, but I have bad news...
Email is messy and imperfect and largely run by people and orgs whose
behavior is not well-described by the word "sane."
Telling them "no" when it isn't sane to tell them yes is sane
behavior. If it isn't, then telling any end user anywhere at any time
using any application "no" instead of "You have a secure connection"
under any any every circumstance including ones in which the
connection is in fact not secure, would be equally as insane
regardless of their choice in protocol.
How is that in any way relevant to the use of TLSv1.0 between MTAs
speaking SMTP?
There is no end user involved. There is no "You have a secure
connection" assertion by either side except for a mutual agreement on
which specific ciphers and protocols to use. When STARTTLS fails in
SMTP, there may not even be a new connection made before the client goes
ahead in plaintext.
The government wire tapping the upstream provider to catch your
packets isn't going to say "Oh this is SMTP, I'm not supposed to touch
it." There's no universal bro code to leave SMTP alone and only spy on
HTTP activity.
That's really not it.
Catching packets and analyzing them is not all that is involved in
compromising a TLSv1.0 or 1.1 session. All of the attacks I am aware of
require the ability to elicit a lot of repeated or predictable traffic
between server and client on one session. This can be feasible when the
underlying protocol is HTTP, but is not feasible with SMTP.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
_______________________________________________
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop
