Heho,
We did some measurements on this recently, see:
https://www.usenix.org/system/files/atc22-holzbauer.pdf
At the moment, I’d say that you still lose _some_ destinations (and delivering
MTAs) by forcing TLS (~10% of smaller providers). This is _any_ TLS; Numbers
for disabling 1.0/1.1
Hi MailOps
We were having a discussion on the possibility to disable TLS 1.0 and 1.1 for
MTA to MTA communication, and based on the numbers we've seen so far, it
doesn't look that far fetched.
What's the common consensus in the mail community about this currently?
It's already been
My main question would be: what do you hope to gain?
There are some legit senders who still use non-encrypted mail. And as long as
we don't want to take on the tedious task of educating those senders or
convincing our users that they don't want to get mail from those senders, we
need to allow
On Wed, 3 Aug 2022, Sidsel Jensen via mailop wrote:
Hi MailOps
We were having a discussion on the possibility to disable TLS 1.0
and 1.1 for MTA to MTA communication, and based on the numbers we've
seen so far, it doesn't look that far fetched.
What's the common consensus in the mail
We were having a discussion on the possibility to disable TLS 1.0 and
1.1 for MTA to MTA communication, and based on the numbers we've seen
so far, it doesn't look that far fetched.
And what about PLAIN - do you still allow that as the fallback option
or are you also considering disabling
But you must take into account the difference between web and e-mail.
With
HTTPS, the connection is directly between your browser and the server,
so if
it's secure, it's secure (as long as you trust the server). Period.
This leans on faulty logic. If the browser is on the screen of a laptop
On 03/08/2022 20:01, Jarland Donnell via mailop wrote:
> End users get headers which is admittedly not useful to most, but the
> "lock" on Gmail is at least fast becoming an accepted thing, seeing more
> email clients latch onto that is a bit slow but is happening. Of course,
> it should only
Ahoj,
Dňa Wed, 3 Aug 2022 13:34:02 +0200 (CEST) Sidsel Jensen via mailop
napísal:
> Hi MailOps
>
> We were having a discussion on the possibility to disable TLS 1.0 and
> 1.1 for MTA to MTA communication, and based on the numbers we've seen
> so far, it doesn't look that far fetched. What's
Roger that. So this:
Specifically "plain text to be more secure than insecure SSL".
It's about proper documentation, expectation, and communication. The
most secure line is the actual secure line, the least secure line is the
one that says "I am secure" and isn't. This might sound confusing
The MTA-MTA encryption is weak at best: because the client doesn't
(can't, actually) verify that the certificate is appropriate for that
MTA, any MITM attack is easily accomplished. End users get virtually
no indication that the message was or wasn't encrypted in transit, and
there is no
Dnia 3.08.2022 o godz. 14:28:43 Jarland Donnell via mailop pisze:
> > There's nothing that requires you to log a TLS 1.0/1.1 connection as
> > being secure. You could choose to log it as if it were plaintext. It's
> > likely to be logged with the protocol and cipher information.
>
> What you log
Disabling support for less secure transport encryption protocols
doesn't increase security if the senders can then switch to unencrypted
transport as a fallback.
It's a pretty big and well respected security practice to consider plain
text to be more secure than insecure SSL for one reason: A
On 8/3/22 11:34 AM, Jarland Donnell via mailop wrote:
I mean, do you honestly want to admit publicly that you don't understand
why it's a good security practice to disable insecure SSL protocols and
ciphers? I shouldn't even have to point to that, you should have to
already know that to be
If you must divulge your SSN over the phone (for reasons) do you just
blurt it out at normal volume indifferent to who is around? Or do you
walk to a secluded corner of the room and cup your hand around the
mouth piece? Even questionable security is better than no security in
many cases.
No,
On Wed, 3 Aug 2022, Grant Taylor via mailop wrote:
On 8/3/22 6:26 AM, Taavi Eomäe via mailop wrote:
Lastly, RFC8314 (re)defines port 465 as implicit TLS SMTP submission port.
Implicit TLS is considered a significantly better approach than upgrading
connections. Do you support that?
There
On 8/3/22 12:14 PM, Jarland Donnell via mailop wrote:
Roger that. So this:
;-)
It's about proper documentation, expectation, and communication. The
most secure line is the actual secure line,
I can't agree.
I suspect we can agree that security is not binary / black & white.
Stock DES was
On 8/3/22 9:46 AM, Jarland Donnell via mailop wrote:
It's a pretty big and well respected security practice to consider plain
text to be more secure than insecure SSL for one reason: A plain text
connection isn't logged or reported as a secure connection.
What‽‽‽
Please elaborate. Please
On 8/3/22 6:26 AM, Taavi Eomäe via mailop wrote:
Lastly, RFC8314 (re)defines port 465 as implicit TLS SMTP submission
port. Implicit TLS is considered a significantly better approach than
upgrading connections. Do you support that?
There are times that I question the actual security
I mean, do you honestly want to admit publicly that you don't understand
why it's a good security practice to disable insecure SSL protocols and
ciphers? I shouldn't even have to point to that, you should have to
already know that to be given root to anything.
On 2022-08-03 12:03, Grant
On 8/3/22 12:11 PM, Andrew C Aitchison via mailop wrote:
What you mean by "actual security differences" may be significant.
I figured that there were things that I wasn't aware of. Hence playing
the part of the fool to learn.
IIUC the "No STARTTLS" people have found that, when connecting a
Genuine question though: What differentiates a client from a remote SMTP
server besides emotional attachment?
A remote SMTP server should not be told "This is a secure line" when it
isn't, in just the same way and for the same reasons, that a client
shouldn't be told "This is a secure
We were having a discussion on the possibility to disable TLS 1.0 and 1.1 for
MTA to MTA communication, and based on the numbers we've seen so far, it
doesn't look that far fetched.
What's the common consensus in the mail community about this currently?
I don't really see the point, unless
On Wed, 3 Aug 2022 13:34:02 +0200 (CEST), Sidsel Jensen via mailop
wrote:
>We were having a discussion on the possibility to disable TLS 1.0 and 1.1 for
>MTA to MTA communication, and based on the numbers we've seen so far, it
>doesn't look that far fetched.
Our analysis states that the most
On Wed, Aug 3, 2022 at 10:07 AM Grant Taylor via mailop
wrote:
> On 8/3/22 9:46 AM, Jarland Donnell via mailop wrote:
> > It's a pretty big and well respected security practice to consider plain
> > text to be more secure than insecure SSL for one reason: A plain text
> > connection isn't logged
On 2022-08-03 at 13:37:56 UTC-0400 (Wed, 03 Aug 2022 12:37:56 -0500)
Jarland Donnell via mailop
is rumored to have said:
>> If you must divulge your SSN over the phone (for reasons) do you just
> blurt it out at normal volume indifferent to who is around? Or do you
> walk to a secluded corner
On 03/08/2022 16:46, Jarland Donnell via mailop wrote:
> It's a pretty big and well respected security practice to consider plain
> text to be more secure than insecure SSL for one reason: A plain text
> connection isn't logged or reported as a secure connection. Both being
There's nothing
There's nothing that requires you to log a TLS 1.0/1.1 connection as
being secure. You could choose to log it as if it were plaintext. It's
likely to be logged with the protocol and cipher information.
What you log it as isn't as important as what the other party logs it
as. Sure if it were
Dnia 3.08.2022 o godz. 13:14:07 Jarland Donnell via mailop pisze:
>
> It's about proper documentation, expectation, and communication. The most
> secure line is the actual secure line, the least secure line is the one that
> says "I am secure" and isn't. This might sound confusing because most
You clearly see what TLS version and what ciphers were used. So you
know if
it was "secure" in your opinion or not.
I don't understand why Firefox did this:
https://hacks.mozilla.org/2019/05/tls-1-0-and-1-1-removal-update/
Clients can clearly click the lock, check the details, and see which
On 03/08/2022 21:05, Jarland Donnell via mailop wrote:
> I don't understand why Firefox did this:
> https://hacks.mozilla.org/2019/05/tls-1-0-and-1-1-removal-update/
>
> Clients can clearly click the lock, check the details, and see which SSL
> version they're using. So if the site says it's
Dnia 3.08.2022 o godz. 14:46:06 Jarland Donnell via mailop pisze:
> > But you must take into account the difference between web and e-mail.
> > With
> > HTTPS, the connection is directly between your browser and the server,
> > so if
> > it's secure, it's secure (as long as you trust the server).
Am 04.08.22 um 00:03 schrieb Bill Cole via mailop:
A MTA that can't get STARTTLS to work will retry (or even continue in the same
session) without encryption, as it SHOULD per the standard.
Erm, no, it doesn't. And that's not how RFC 3207 defines things, anyway:
After receiving a 220
On 8/3/22 12:33 PM, Jarland Donnell via mailop wrote:
Else, why are there even any articles about old versions being insecure?
Why are there any efforts to remove old TLS versions from every major
software application and operating system?
There is nothing wrong with striving for better.
But
On 2022-08-03 at 17:32:56 UTC-0400 (Wed, 03 Aug 2022 16:32:56 -0500)
Jarland Donnell via mailop
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?
On Wed, Aug 03, 2022 at 03:05:43PM -0500, Jarland Donnell via mailop wrote:
> > You clearly see what TLS version and what ciphers were used. So you know
> > if
> > it was "secure" in your opinion or not.
> I don't understand why Firefox did this:
>
A generic "confirmation of a secure connection" is not a part of any
MTA-MTA interaction.
I mean if our standard is so high that it needs to be a flashing neon
sign then neither does a web browser or any other piece of software. I
cannot believe that I am in a mailing list full of
On 8/3/22 6:51 PM, Jarland Donnell via mailop wrote:
I cannot believe that I am in a mailing list full of professional
admins that is universally speaking up on this topic to ONLY state
that there is zero merit to a best security practice of disallowing
insecure SSL protocols and ciphers for
Dňa 3. augusta 2022 19:46:06 UTC používateľ Jarland Donnell via mailop
napísal:
>You have SSL because you want to not only know that the server you are
>connecting to is who they say they are, but also to secure the packets as they
>transmit to your ISP, to their upstream, to the next
On 2022-08-03 at 14:33:36 UTC-0400 (Wed, 03 Aug 2022 13:33:36 -0500)
Jarland Donnell via mailop
is rumored to have said:
Genuine question though: What differentiates a client from a remote
SMTP server besides emotional attachment?
See RFC821. It uses "receiver-SMTP" and "sender-SMTP" rather
On 8/3/22 1:46 PM, Jarland Donnell via mailop wrote:
This leans on faulty logic. If the browser is on the screen of a laptop
plugged directly into the server, sitting in the middle of that place
that sounds suspiciously like an airport, then this would be true. But
then, if you trust the
Why are there any efforts to remove old TLS versions from every major
software application and operating system? Are all of these security
experts and corporations just playing a game with TLS versions, or is
there perhaps something to this security practice?
Because browsers won't fall back
On 2022/08/03 14:01, Jarland Donnell via mailop wrote:
> > The MTA-MTA encryption is weak at best: because the client doesn't
> > (can't, actually) verify that the certificate is appropriate for that
> > MTA, any MITM attack is easily accomplished. End users get virtually no
> > indication that
On 8/3/22 1:26 PM, Jaroslaw Rafa via mailop wrote:
But you must take into account the difference between web and
e-mail. With HTTPS, the connection is directly between your browser
and the server, so if it's secure, it's secure (as long as you trust
the server). Period.
Sadly, I don't think
On Wed, Aug 03, 2022 at 02:46:06PM -0500, Jarland Donnell via mailop wrote:
> You have SSL because you want to not only know that the server you are
> connecting to is who they say they are, but also to secure the packets as
> they transmit to your ISP, to their upstream, to the next upstream,
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? I'm talking about a general
acceptance of the idea that a user should not be given a false sense of
security by being
Moin,
am 03.08.22 um 13:34 schrieb Sidsel Jensen via mailop:
We were having a discussion on the possibility to disable TLS 1.0 and 1.1 for
MTA to MTA communication, and based on the numbers we've seen so far, it
doesn't look that far fetched.
[…] but have you also disabled it for MTA to MTA
It appears that Sidsel Jensen via mailop said:
>-=-=-=-=-=-
>-=-=-=-=-=-
>
>Hi MailOps
>
>We were having a discussion on the possibility to disable TLS 1.0 and 1.1 for
>MTA to MTA communication, and based on the numbers we've seen so
>far, it doesn't look that far fetched.
>
>What's the common
47 matches
Mail list logo