Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[John Levine via mailop]

It appears that Bastian Blank via mailop  said:
>MTA-STS is supposed to fix that, by providing a secure way to translate
>from domain to MX via a medium break.
>
>So is DANE, which requires DNSSEC on the whole thing and translates from
>domain -> MX -> key via DNSSEC validated DNS.

I do both on my MTA and I can confirm that they work, since I found that
when I screwed up the certificates, mail from places that check them, notably
Comcast, stopped arriving.

While I encourage people to try MTA-STS and DANE, they don't have
anything to do with the TLS 1.0 question, since I'm still not seeing a
plausible attack (and I emphasize plausible) that TLS 1.0 enables.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Grant Taylor via mailop]

On 8/4/22 11:03 AM, Taavi Eomäe via mailop wrote:
You're correct. My perspective on the UI might be different because of 
how S/MIME encrypted (or signed) letters look like in Gmail.


I see a white check mark in a green circle for S/MIME signed messages 
below the sender's name near the from: line in the same drop down / 
hover card.


The padlock on the security: line is the same grey color.

I didn't consider a gray padlock an indication of "being secure" 
when it could've been... well, green. But I guess some users might.


Perhaps this should be tweaked to be something like "transport: TLS 
(...) encrypted" / "transport: unencrypted".




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Taavi Eomäe via mailop]

Gmail has a "security" line in the drop down which shows more 
information about the sender, recipients, etc.  I have many messages 
in a mailbox that state:


   security:  Standard encryption (TLS) Learn more

With a padlock icon in front of Standard and Learn more being a link.

So there is some amount of information being surfaced to user -- if 
they know where to look -- indicating that the message is secure.


You're correct. My perspective on the UI might be different because of 
how S/MIME encrypted (or signed) letters look like in Gmail. I didn't 
consider a gray padlock an indication of "being secure" when it could've 
been... well, green. But I guess some users might.


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Grant Taylor via mailop]

On 8/4/22 3:38 AM, Slavko via mailop wrote:
In SMTP (the historically) the autentification is missing, thus MTA 
are possible target of MtM attack, but that is only because MTA often 
doesn't do it, not because it is useless or impossible. Eg. recent 
Debian enables certificate verification by default on its exim.


It is. While to be secure has (can have) multiple levels, once 
threshold is reached things becomes insecure. That threshold can 
differ as already pointed by Brandon and by you too ("reasonable 
cipher restrictions").


I am surprised that no one mention the RFC 8996 (or at least i didn' 
notice). It clearly defines technical reasons why the TLS 1.0 and 
1.1 are deprecated. It is BCP (Best Current Practices) -- for those 
who ask "where is documented" the practice to don't use weak security.


The "where is the documentation" that I asked is specifically related to 
"plain text being more secure than weak cipher text" comments.


What more the SMTP world need? The TLS 1.1 itself was deprecated in 
2008, thus anyone have to question itself, why in hell is it still 
in use 14 years latter? My answer is, because it is accepted by 
remote side...


I feel like the venerable "be liberal in what you accept and 
conservative in what you send" comes into play here.  As does "brown M".


So I can see room for MTAs to allow reception in $OLDER TLS, where 
$OLDER is a local definition, while sending is only in newer TLS.  Thus 
providing backward compatibility for older sending systems while 
protecting outgoing SMTP transactions.


But yes, the fallback to plaintext is unique for SMTP, and IMO 
it is here for historical reasons and for internal communication, 
not for wide use.  And the Internet's world changed in last years 
(after Snowden).


I don't know how much lack of fallback to plaintext would have changed 
this thread.  It definitely would have started (or been hijacked) 
differently, but I feel like there is at least some content that would 
still be germane if SMTP didn't have fallback to plaintext.


And last words why i agree that plain text is better than weak 
seacurity.  Of course, even weak security can lower the amount of 
success attacks on transport, at price more resources consumed. But, 
as this threa shows, multiple people consider  that when they 
use TLS, they are safe, without taking into acount if particular 
ciphersuite provides security at expected level or not, and that can 
lead into false security feel. And that false security is worse that 
no security at all, as one can do wrong decision on it, especially 
when its weakness is not as obvious, and current cryptology is not 
straightforward nor simple.


Cisco's type 7 password hash comes to mind.  Obviously type 7 is not 
strong as it's relatively easy to reverse.  However, type 7 is only 
meant to protect against over the shoulder attacks.


I think it's prudent to notice that the different type numbers are 
clearly visible in context.  Similarly the different types ~> versions 
of TLS are visible.  Both require people trained in the art to recognize 
and appreciate the significance of the numbers.


And that is as i understand the sentence "plain text is better than 
weak security" and why i agree with it.


To each their own.

I'm still not convinced.

We seem to be at a point that we will need to agree to disagree.  Or 
have an even more protracted discussion that will likely have lower and 
lower ROI.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Grant Taylor via mailop]

On 8/4/22 2:24 AM, Taavi Eomäe via mailop wrote:
Nobody (and rightfully so) displays transport encryption as secure, 
which invalidates the original premise of someone being lied to in 
the first place.


I question the veracity of that.

Gmail has a "security" line in the drop down which shows more 
information about the sender, recipients, etc.  I have many messages in 
a mailbox that state:


   security:  Standard encryption (TLS) Learn more

With a padlock icon in front of Standard and Learn more being a link.

So there is some amount of information being surfaced to user -- if they 
know where to look -- indicating that the message is secure.


This is also conceptually similar to people describing web sites as 
secure because they have the padlock in the address bar.  This is 
usually erroneously extrapolated as being safe to visit.  Yet malware 
and viruses distributed by such secure ~> safe sites are anything but 
safe to visit.  --  I consider this to be a questionable UI / UX / 
training / conditioning problem more than I consider it to be a 
technological problem.  --  In some ways I feel like some of, if not 
much of, the spirit of this -- hijacked -- (sub)thread suffers from the 
same thing.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Grant Taylor via mailop]

On 8/4/22 12:25 AM, Paul Smith via mailop wrote:
Attacks against TLS1.0 work using HTTP. I am not aware of any viable 
attack method which can be made using SMTP


I do think it behooves people to learn from attack vectors of other 
protocols (e.g. HTTP) to make sure that main protocol of focus (SMTP) is 
not vulnerable from them.


Let's learn from each others foibles and help each other avoid them.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Andrew C Aitchison via mailop]

On Wed, 3 Aug 2022, Hans-Martin Mosner via mailop wrote:


Disabling support for less secure transport encryption protocols
doesn't increase security if the senders can then switch to
unencrypted transport as a fallback.


We seem to be assuming that this is about protecting the current message.

It may be that the original poster wishes to pro-actively protect
his server (or, as in the case of DROWN, all of his servers) against 
unknown vulnerabilities in encryptions he does not need.


I note from 
https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

and
https://github.com/Mbed-TLS/mbedtls/blob/93a3ca6caf20e0e1a90c86ee2fc03e9f1fb4ebfa/ChangeLog
that Mbed TLS v3.0 suports nothing older than v1.2
which *could* mean that it has a smaller attack surface than
implementations which do support v1.0 and/or v1.1
and that it is immune to flaws in the protocol
(though my guess is that v1.2 might share those flaws
even if v1.3 does not).

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Grant Taylor via mailop]

On 8/4/22 2:28 AM, Bastian Blank via mailop wrote:
And even if you had verifiable certificates: which ID would you use 
to verify it?


I would naively use the name that you are connecting to.  E.g. my MTA is 
connecting to the FQDN in the MX record or in a B2B configuration.


The name of the MX is not secure, as it is resolved using unsecured 
DNS.


DNSSEC.


The only secure value you have on the mail is the remote domain.


Nothing about the example.org domain reflects the fact that they have 
outsourced email service to example.com.  Nor can example.org 
realistically publish and maintain things per example.com's direction.



However, who lists the domains in the certificate?


The MTA operator lists the FQDN(s) of the MTAs that use said certificate.

MTA-STS is supposed to fix that, by providing a secure way to translate 
from domain to MX via a medium break.


I see MTA-STS as something different.  Namely I see MTA-STS as a way for 
a sending MTA to learn that a destination MTA is supposed to use TLS and 
thus should be an indication of a problem if said destination MTA 
doesn't offer STARTTLS.


So is DANE, which requires DNSSEC on the whole thing and translates 
from domain -> MX -> key via DNSSEC validated DNS.


Yes.  However, sadly, my understanding is that there are more things 
that use MTA-STS than there are things that use DANE.



But MITM is way harder then just passive extraction of the cleartext.


It *REALLY* depends where you are in the communications path and if you 
mind being detected or not.  E.g. it's trivial to do a MITM in a D.R. 
Exercise where you control the Internet choke point and want to redirect 
to a local spoofed instance of 8.8.8.8 et al.  It's not so easy when you 
want ot attack something from across the Internet without someone (else) 
on the Internet knowing that you're doing so.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Jaroslaw Rafa via mailop]

Dnia  4.08.2022 o godz. 12:51:21 Gellner, Oliver via mailop pisze:
> 
> A TLS encrypted SMTP connection protects against eavesdropping or altering
> of messages through MITM attacks, which can be either passive or active:

No. As long as certificates are not checked (and on MTA-to-MTA connections
they generally aren't), MITM is always possible. The MITM box will simply
speak TLS (even 1.2) to both MTAs using its own certificate. The MTAs won't
see the difference.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Gellner, Oliver via mailop]

> Am 03.08.2022 um 13:48 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.

As long as the MTA in question supports plaintext SMTP connections, disabling 
TLS 1.0 or 1.1 will not improve security of public, anonymous MTA to MTA 
connections, but *decrease* it, for the following reasons:

A TLS encrypted SMTP connection protects against eavesdropping or altering of 
messages through MITM attacks, which can be either passive or active:

a) An active MITM will simply strip off the STARTTLS keyword (always 
transmitted in the clear), thereby forcing the involved MTAs to fall back to 
plaintext communication. There are ready to be used tools to achieve that and 
it is infinitely easier to perform this attack than breaking even the oldest 
ciphersuites.
So with an active MITM it doesn‘t matter if a MTA supports TLS 1.0, 1.2 or 
whatever version, because no TLS at all will ever be part of the connection.

b) A passive MITM on the other hand will not be able to perform a downgrade 
attack (because well… he would be an active attacker in this case, for which 
see above). So if both MTAs support TLS 1.2 and a common ciphersuite, they are 
going to use that. It doesn‘t lower the security if one MTA additionally 
supports older SSL/TLS versions, as long as he tries with the newest first.
If however the other MTA *only* supports TLS 1.0, disabling this version on 
your MTA will result in the connection falling back to plaintext, at least the 
MTA software I know of behaves this way. So instead of seeing a TLS 1.0 
encrypted SMTP connection, which is next to impossible to break for a passive 
MITM, the attacker will instead be able to simply read everything in plaintext. 
Game over.

For those reasons I recommend (again for public, anonymous SMTP connections) to 
enable all SSL and TLS versions that the system in use provides. This holds 
true until unencrypted SMTP connections are disabled and/or DANE gets any 
widespread usage.

MTA-STS is out of scope here, since it restricts TLS to version 1.2 or higher 
anyway, regardless if a MTA would theoretically support older versions as well.

For selected targets where you know that they support TLS 1.2 it makes sense to 
enforce this of course. The same is true for MUA submission, which should be 
restricted to implicit TLS 1.2 or newer (no STARTTLS support).

Regarding the claims in this thread that TLS 1.0 would be as insecure as 
plaintext: I‘m honestly interested to learn about an attack against a TLS 1.0 
encrypted SMTP connection by a passive attacker.

—
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Kai Bojens via mailop]

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.

What's the common consensus in the mail community about this currently?


Disable it.

RFC 8996: "This document formally deprecates Transport Layer Security
(TLS) versions 1.0 (RFC 2246) and 1.1 (RFC 4346).  Accordingly, those
documents have been moved to Historic status." (March 2021)

Mail servers with support for TLS 1.0 only have not been updated for 
years and are very clearly a security risk.


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Slavko via mailop]

Dňa 3. augusta 2022 22:03:49 UTC používateľ Bill Cole via mailop 
 napísal:

>> A remote SMTP server should not be told "This is a secure line" when it 
>> isn't,
>
>And it never is. Nothing ever says "This is a secure line" in TLS. The 2 
>participants negotiate a specific set of security features. There's no such 
>thing as a secure/insecure binary.

At least the RFC 8446 in section 1 tells:

The primary goal of TLS is to provide a secure channel between two
communicating peers; the only requirement from the underlying transport
is a reliable, in-order data stream.

When we replace line by channel, then it is the same... Then there
are defined parts, which makes channel secure, the obvious
authentication, confidentiality and integrity with the word SHOULD, thus
not all have to be provided.

In SMTP (the historically) the autentification is missing, thus MTA are
possible target of MtM attack, but that is only because MTA often
doesn't do it, not because it is useless or impossible. Eg. recent Debian
enables certificate verification by default on its exim.

Modern MTA are able to use SNI, and most (from my logs) are using
it, then it is possible even to provide public cert on per domain base and
verify it over PKI. Of course, if someone uses self-signed certificate, only
DANE can verify it in public. But nowadays anyone can have public
certificate for free, thus using self-signed one is not required.

The next, confidentiality and integrity, is protection on the transport
against spying and/or modification. This is often considered as
useless in SMTP, because (as sameone pont it), the message is not
protected in SMTP servers itself. While the latest is true, the TLS is
not message protection, but the transport itself, thus protection agains
attacks on line. Consider how many hops is between two MTA serfers
and any of them can be exploted by anyone and no one from SMTP
parts can prevent it.

>Or the SMTP client is some black box that sends mail a few times a year when 
>something breaks, and there's no way to update its SSL library

We are talking about public MTA-MTA communication, if that is really
client, it has to use submission, or have to connect to dedicated MTA.
Or do you expect, that whole world have to support deprecated things
for your (and others) old blackbox?

>Using TLS1.0 with reasonable cipher restrictions is never less secure than 
>just using plaintext. That is what matters.

That is main point, the "reasonable cipher restrictions". Particular TLS
versions have defined required cipersuites. If you do not provide all its
required cipersuites, you do not provide particular TLS version.

The RFC 8996 exactly mentions TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
are you providing it? I will guess that no. And why not? Because it is
not considered to provide enough confidentality. What that means? Securing
content by weak cipher is resource wasting, without any (or with minimal)
value of protection.

And there are multiple ciphersuites in old TLS, which are not considered
weak itself, but they are prone to wrong implementation which results
in their weakness. That is even worse as weak ciphersuites, as one
cannot reliably know how it is implemented on remote side.

>Thinking of security as an on/off switch is not useful. Thinking of security 
>mechanisms as vulnerable/invulnerable is not useful.

It is. While to be secure has (can have) multiple levels, once threshold
is reached things becomes insecure. That threshold can differ as
already pointed by Brandon and by you too ("reasonable cipher
restrictions").

>Because TLS 1.2 and 1.3 have narrower vulnerabilities and stronger ciphers 
>than older versions. Also because there are attacks against 1.0 which are 
>facilitated by the behavioral model of web browsers and web servers. Those are 
>infeasible with SMTP.

I am surprised that no one mention the RFC 8996 (or at least i didn'
notice). It clearly defines technical reasons why the TLS 1.0 and 1.1
are deprecated. It is BCP (Best Current Practices) -- for those who
ask "where is documented" the practice to don't use weak security.

Beside this, its sections 4 and 5 it tells:

TLS 1.0 (1.1) MUST NOT be used. Negotiation of TLS 1.0
(1.1) from any version of TLS MUST NOT be permitted. ...

What more the SMTP world need? The TLS 1.1 itself was deprecated
in 2008, thus anyone have to question itself, why in hell is it still in
use 14 years latter? My answer is, because it is accepted by remote
side...

>The overwhelming majority of TLS usage is with protocols which have no 
>mechanism to fall back to plaintext automatically if a TLS session can't be 
>established. If you're trying to log into a website and the TLS negotiation 
>fails, your web browser won't retry the failed https URL as a http URL. 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. That calls for 
>different configuration than a 

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Jaroslaw Rafa via mailop]

Dnia  3.08.2022 o godz. 19:51:24 Jarland Donnell via mailop pisze:
> Either allowing an end user to negotiate a secure connection, to which their
> software absolutely acknowledges it as a secure connection, is either sane
> or it isn't. Ignore the protocol. Ignore the software. Either it's sane to
> shake hands and agree that a connection is secure, when it isn't, or it's
> not.

How many times people have to explain to you that security does not work this
way?

There is no such thing as absolutely secure. There is no such thing as clear
binary distinction "either secure or insecure". YOUR ASSUMPTIONS ARE FALSE.

There is only some (lower or higher) *level* of security, which should match
the potential risk.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Bastian Blank via mailop]

Moin

On Thu, Aug 04, 2022 at 12:51:29AM +0100, Stuart Henderson via mailop wrote:
> I think when acting as SMTP-over-TLS clients, most MTAs out there are
> not checking the server's certificate in any really meaningful way; they
> can usually be configured to do so but, last time I looked, there were
> plenty of expired certs, mismatching host names, and self-signed certs,
> and based on what I've seen with web servers I'd expect to see more than
> a few with valid CA-signed certs, but with no chain cert presented.
> Turning this on for general use (rather than for specific destinations)
> would seem likely to result in a lot of failures.

And even if you had verifiable certificates: which ID would you use to
verify it?  The name of the MX is not secure, as it is resolved using
unsecured DNS.  The only secure value you have on the mail is the remote
domain.  However, who lists the domains in the certificate?

MTA-STS is supposed to fix that, by providing a secure way to translate
from domain to MX via a medium break.

So is DANE, which requires DNSSEC on the whole thing and translates from
domain -> MX -> key via DNSSEC validated DNS.

> Without cert verification, there seems little point in requiring stronger
> TLS versions. Rather than trying to break a weaker encryption protocol
> (usually still relatively hard) an attacker could MITM with their own
> cert.

But MITM is way harder then just passive extraction of the cleartext.

Bastian

-- 
The joys of love made her human and the agonies of love destroyed her.
-- Spock, "Requiem for Methuselah", stardate 5842.8
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Taavi Eomäe via mailop]

The (very important) thing is that NO email can be considered "secure" 
unless it is end-to-end encrypted (eg PGP), without any third party 
service knowing the encryption key, or you personally know and trust 
all the mail administrators of all the mail servers involved.


Exactly the point I tried to make. Nobody (and rightfully so) displays 
transport encryption as secure, which invalidates the original premise 
of someone being lied to in the first place.


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Paul Smith via mailop]

On 3 August 2022 23:43:36 Taavi Eomäe via mailop
You can't consider it a lie if nobody is asking the question in the first 
place. Gmail might show when an email was delivered in plaintext as 
insecure it does not display transport-encrypted emails as secure. What 
displays transport encryption as  "secure"?


The (very important) thing is that NO email can be considered "secure" 
unless it is end-to-end encrypted (eg PGP), without any third party service 
knowing the encryption key, or you personally know and trust all the mail 
administrators of all the mail servers involved.


By definition, if you're reading an email on Gmail (or Outlook.com, 
Yahoo.com, etc), it is *not* secure. If your email has passed through your, 
or the recipient's ISP's mail server, or a spam filtering service, or a 
random MTA, it is not secure unless it is end to end encrypted.


Any suggestion otherwise that an email is "secure" is false, even if it's 
been transmitted over all hops using TLS1.3


It is *arguably* more secure to transmit using TLS1.2 than TLS 1.0. It is 
definitely more secure to transmit using TLS 1.0 than plain text


Attacks against TLS1.0 work using HTTP. I am not aware of any viable attack 
method which can be made using SMTP


Paul



--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[John Levine via mailop]

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 consensus in the mail community about this currently?

Here's the numbers for my main mail server for the past month:

13728 TLS1.0
   9 TLS1.1
345996 TLS1.2
17480 TLS1.3

I took a look at some of the TLS1.0 connections, and while most of
them were from spambots, at least one of them was from the author of
RFC 5321 so maybe I won't change my settings just yet.

I agree with everyone who pointed out that a threat model that finds
TLS1.0 to be a problem on SMTP connections is not a very good threat model.

R's,
John
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Kai 'wusel' Siering via mailop]

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 response to a STARTTLS command, the client MUST
   start the TLS negotiation before giving any other SMTP commands.  If,
   after having issued the STARTTLS command, the client finds out that
   some failure prevents it from actually starting a TLS handshake, then
   it SHOULD abort the connection.


Repeat after me: it SHOULD abort the connection. (At least some sendmail code 
runs in a timeout here, which then leads to an aborted connection — basically 
fine by the RFC.)

Guess what happens on the next queue run ...

Point is: there is no defined fallback to 1982. If STARTTLS does not result in a 
TLS-secured connection, the _expected_ behaviour is to abort the SMTP connection. If the 
MTA marks that message as "STARTTLS failed already once, try without next time" 
is totally up to the implementor.

And, frankly, I wouldn't care to carry this state anyway. Let's look at RFC 
3207 again:


   The SMTP client and server should note carefully the result of the
   TLS negotiation.  If the negotiation results in no privacy, or if it
   results in privacy using algorithms or key lengths that are deemed
   not strong enough, or if the authentication is not good enough for
   either party, the client may choose to end the SMTP session with an
   immediate QUIT command, or the server may choose to not accept any
   more SMTP commands.


This, to me, reads as "whatever was _ever_ a valid way of engaging in a STARTTLS'd 
SMTP communication has to be supported until the end of time; if you don't like the 
established encryption level, you are free to drop then connection _then_, with a 
meaningful error message". Not supporting legacies like SSLv3, TLS 1.1, etc. at the 
STARTTLS level is _not_ to be considered to be conforming to RFC 3207.

IMHO, YMMV.
-kai

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Grant Taylor via mailop]

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 communication between servers.


FLAG ON THE PLAY!!!  I believe that is an unfair and unnecessary over 
simplification.


It is definitely not a universal opinion.

I suspect that this thread is at least enough of a sampling to question 
the veracity of your previous statement; "a pretty big and well 
respected security practice to consider plain text to be more secure 
than insecure SSL".


Multiple have stated that disabling insecure TLS protocols can be a good 
thing.  Many have said that doing so may be problematic.  I have 
personally stated that it's laudable to try to reach for better 
standards.  None of that equates / simplifies to "zero merit to a 
(supposed) best security practice of disallowing insecure SSL protocols 
and ciphers for communication between servers.".


I took the liberty to add supposed to that quote because I have yet to 
see any evidence of "a pretty big" or "well respected" practice when it 
"consider plain text to be more secure than insecure SSL" in the context 
of SMTP.  I'll even go so far as to include IMAP and POP3 in that list.


I absolutely believe that there is merit to disabling older TLS 
protocols / cypher suites /if/ /you/ /can/.  Meaning /if/ /your/ 
/situation/ /allows/.


I strongly suspect that everybody on this mailing list has received at 
least one managerial directive that dictates we do the exact opposite of 
what we think is technically the best thing to do.  But almost all of us 
will do what we are directed to do.


I believe that most will agree that the PROs for disabling the old TLS 
protocols and cipher suites are quite appealing.  However I strongly 
suspect that many of us will agree that the CONs are more massive.  As 
such it's a matter balancing the PROs and CONs for each situation.


Aside:  I have long been an advocate for practicing what you preach.  So 
with that in mind, please tell us about the PROs and lack of CONs that 
you've experienced in disabling older TLS protocols / old cypher suites 
on /your/ mail server Jarland.  --  I genuinely would like to learn from 
your experience.


Yes, there is some snark there.  But there is /more/ curiosity and 
desire to learn from your experience than there is snark.


I'd be torn a new one and have a reddit thread ripping into me for 
the mere suggestion of what seems to be universal agreement here 
(assuming from lack of diversity of opinion).


As stated above, it is /not/ *universal* agreement.

Either allowing an end user to negotiate a secure connection, to which 
their software absolutely acknowledges it as a secure connection, is 
either sane or it isn't. Ignore the protocol. Ignore the software. 
Either it's sane to shake hands and agree that a connection is secure, 
when it isn't, or it's not.


I think that you're getting so far into software / user interface design 
and user experience that it's so far removed from the original intent of 
this thread as to be non-germane.


Allowing the end user to negotiate a secure connection is perfectly sane.

But what is "a secure connection"?  Similarly what isn't a secure 
connection?  What is your answer for /today/?  What is your answer for 
/next/ /month/, or /next/ /year/, or how about /next/ /decade/? 
Similarly, what was your answer /a/ /decade/ /ago/?


Eudora from '98 will happily negotiate what it thinks is a secure 
connection with Sendmail from '00.  Was Eudora wrong then?  Is it wrong 
now?  It still thinks that it is using the best possible options that it 
knows about.  --  Should we fault Eudora's programmers for not 
supporting a standard that hadn't been developed yet?


And why are the people on this mailing list so scared to let things fall 
back to plain text?


I have yet to see why sending anything as plain text is /better/ than 
sending it as /cyphertext/, independent of what the cypher is.  --  I 
will say that I'm focusing on things that are *encrypted* /with/ /a/ 
/key/.  Meaning that simple /encoding/ is out of scope.



It's still how surely the vast majority of email is done.


Almost /all/ of the SMTP connections that passes through my server are 
encrypted.  Proportionally, very few of them are unencrypted.


If we're agreeing that insecure SSL is sane and that it's safe as long 
as the two servers trust each other,


That's not what is being said.  What /is/ being said is that /older/ 
/TLS/ / /weaker/ /ciphers/ /are/ *BETTER* /than/ /plain/ /text/.


Full stop.

Cypher text off any form is *BETTER* than cleartext.

You want the *best* cypher algorithms /that/ /you/ /can/ /use/.

It's just that many of the SMTP servers on the Internet don't / won't -- 
which doesn't matter much -- support TLS 1.2.


completely ignoring 

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Jarland Donnell via mailop]

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 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 communication between servers. I'd be torn a 
new one and have a reddit thread ripping into me for the mere suggestion 
of what seems to be universal agreement here (assuming from lack of 
diversity of opinion).


Either allowing an end user to negotiate a secure connection, to which 
their software absolutely acknowledges it as a secure connection, is 
either sane or it isn't. Ignore the protocol. Ignore the software. 
Either it's sane to shake hands and agree that a connection is secure, 
when it isn't, or it's not.


And why are the people on this mailing list so scared to let things fall 
back to plain text? It's still how surely the vast majority of email is 
done. If we're agreeing that insecure SSL is sane and that it's safe as 
long as the two servers trust each other, completely ignoring upstreams 
in between as seems to be the agreed upon philosophy in this discussion, 
then there's no harm in them transmitting to each other in plain text. 
If there's no one listening in that can capture plain text traffic and 
compromise your security, then there's no harm in plain text SMTP 
transactions. If there is ANY danger of those things at all, then the 
false sense of security by acknowledging a secure transaction using 
insecure protocols/ciphers is at best equivalent. To walk away feeling 
better about an exploitable packet than a plain text packet doesn't make 
sense, either the information transmitted is secure or it isn't. If it 
isn't transmitted using a secure protocol/cipher, then it isn't secure. 
If you wouldn't transmit it over plain text but you would transmit it 
over TLS 1.0, your logic is simply not justifiable.



On 2022-08-03 18:22, Bill Cole via mailop wrote:

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?


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.

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Kai 'wusel' Siering via mailop]

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 communication as well or are 
you still considering it? And what scenarios are currently holding you back?


STARTTLS implementations out there tend to assume that TLS negotiation after STARTTLS 
just works™. If it doesn't – because someone artificially limited the interoperability –, 
the connection times out and the mails will bounce days later. Fix: 
"try_tls:mx.mailop.org    NO", if the bounces annoy me enough.

To me it's a rather illogical approach to force unencrypted transmission 
instead of at least allowing what basically nowadays is of ROT13 quality. But, 
well, your server, your rules.


And what about PLAIN - do you still allow that as the fallback option or are 
you also considering disabling that?


rfc3207 seems rather clear on this?


   A publicly-referenced SMTP server MUST NOT require use of the
   STARTTLS extension in order to deliver mail locally.  This rule
   prevents the STARTTLS extension from damaging the interoperability of
   the Internet's SMTP infrastructure.  A publicly-referenced SMTP
   server is an SMTP server which runs on port 25 of an Internet host
   listed in the MX record (or A record if an MX record is not present)
   for the domain name on the right hand side of an Internet mail
   address.


Regards,
-kai
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Stuart Henderson via mailop]

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 the message was or wasn't encrypted in transit, and
> > there is no accepted mechanism to force encryption in the first place.
> 
> Why can't an MTA verify a certificate? Postfix seems to do certificate
> verification, for example:
> https://www.postfix.org/TLS_README.html#server_vrfy_client

That's talking about client certificates which is a different matter
than the client verifying the server's certificate.

I think when acting as SMTP-over-TLS clients, most MTAs out there are
not checking the server's certificate in any really meaningful way; they
can usually be configured to do so but, last time I looked, there were
plenty of expired certs, mismatching host names, and self-signed certs,
and based on what I've seen with web servers I'd expect to see more than
a few with valid CA-signed certs, but with no chain cert presented.
Turning this on for general use (rather than for specific destinations)
would seem likely to result in a lot of failures.

Without cert verification, there seems little point in requiring stronger
TLS versions. Rather than trying to break a weaker encryption protocol
(usually still relatively hard) an attacker could MITM with their own
cert.

FWIW https://www.postfix.org/TLS_README.html#client_tls_verify shows
how to enable this for Postfix, but very much recommends against it
on the internet for now.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Bill Cole via mailop]

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?


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

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Bill Cole via mailop]

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 than 
'server' and 'client' but the meaning is identicval. One side of a SMTP 
sessioin is a client and the other is a serv er. Absent support for the 
obsolete and deprecated TURN command, that relationship is fixed for the 
life of a SMTP session.


A remote SMTP server should not be told "This is a secure line" when 
it isn't,


And it never is. Nothing ever says "This is a secure line" in TLS. The 2 
participants negotiate a specific set of security features. There's no 
such thing as a secure/insecure binary.


in just the same way and for the same reasons, that a client shouldn't 
be told "This is a secure website" in Firefox when it isn't. By the 
very fact alone that a remote SMTP server is connecting to yours over 
TLS 1.0 we can reasonably deduce that the person on the other side is 
not to be considered to be okay. Either they don't know how to manage 
their server


Or the SMTP client is some black box that sends mail a few times a year 
when something breaks, and there's no way to update its SSL library.



or they are the victim of a server side downgrade attack.


Are you aware of how such an attack might work in the specific case of a 
SMTP client using STARTTLS? Have you given the question any thought?


You can't only react to security you have to be proactive, and just 
because I've never seen someone be the victim of a downgrade attack on 
a Postfix install doesn't mean that it isn't the best security 
practice to protect against that.


Using TLS1.0 with reasonable cipher restrictions is never less secure 
than just using plaintext. That is what matters.


Thinking of security as an on/off switch is not useful. Thinking of 
security mechanisms as vulnerable/invulnerable is not useful.


Else, why are there even any articles about old versions being 
insecure?


To describe the specific vulnerabilities, I suppose. Are you familiar 
with them?


Why are there any efforts to remove old TLS versions from every major 
software application and operating system?


Because TLS 1.2 and 1.3 have narrower vulnerabilities and stronger 
ciphers than older versions. Also because there are attacks against 1.0 
which are facilitated by the behavioral model of web browsers and web 
servers. Those are infeasible with SMTP.


Are all of these security experts and corporations just playing a game 
with TLS versions, or is there perhaps something to this security 
practice?


The overwhelming majority of TLS usage is with protocols which have no 
mechanism to fall back to plaintext automatically if a TLS session can't 
be established. If you're trying to log into a website and the TLS 
negotiation fails, your web browser won't retry the failed https URL as 
a http URL. 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. That calls for different configuration than a web server or 
web browser or any other common use of TLS. Most people managing 
TLS-enabled systems don't manage MTAs that talk to the open net, so 
generic TLS security advice doesn't always apply to MTAs.






On 2022-08-03 13:16, Bill Cole via mailop wrote:

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 of the room and cup your hand around the
mouth piece?  Even questionable security is better than no security 
in

many cases.

No, it isn't. It isn't security at all. If you call someone and tell 
them you need their SSN and they ask "Is this a secure line?" If 
it's not, you're supposed to say "No." You're not supposed to say 
"This is a secure line" and leave unstated the subtext of "If you 
didn't do your research to know why this isn't a secure line, it's 
your problem." It's on you when you say "Yes" to "Is this secure?" 
when it isn't secure.


But that's not at issue with allowing TLS 1.0 and 1.1 in SMTP. 
Clients

aren't "told" a session is "secure," they *negotiate* a session's
specific security features in a deterministic manner. Presumably a
client that can't do TLS 1.2 or 1.3 has no expectation of any better
security than they can get with whatever TLS versions they can do.

If you believe that either of those older versions of TLS is as
vulnerable as plain text, please specify why. As far as I am aware,
the only problems with them are inclusion of some weak (but not
trivially so) ciphers by default and attacks that can't work against 
a

typical SMTP server.

___

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Taavi Eomäe via mailop]

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 to plaintext, there are even methods to 
further prevent that (HSTS). Not to mention that web servers will 
upgrade their offering in order to stay accessible. They have the agility.


If you've got validated certificates and MTA-STS in the play and some 
megacorporations flipping that switch on MTAs then we could do the same, 
but that isn't the case. We don't even have MUA-STS, the two ecosystems 
are just so far apart at this point in terms of cryptography that these 
comparisons are borderline bad.


Both being insecure, only one of the two involves your server 
negotiating and reporting to the third party that you are accepting it 
over a secure connection. Which is basically a lie. Plain isn't a lie, 
and that's worth something. 


You can't consider it a lie if nobody is asking the question in the 
first place. Gmail /might/ show when an email was delivered in plaintext 
as *insecure* it does not display transport-encrypted emails as 
*secure*. What displays transport encryption as  "secure"?


Where as if you say "This is a secure line" and it isn't because the 
other party either doesn't know what they're doing or is the victim of 
a downgrade attack (through whatever attack vector that came from) 
then the other party walks away saying "I transmitted secure data" and 
to them it's over. Playing either role in that situation is bad, but 
being the intelligent admin who cares none for the other guy is worse 
than just saying up front: "This isn't secure, plan accordingly." 


That's not correct in this case though, without MTA-STS (which 
is**rare), it will just be transmitted in plaintext. The "plan 
accordingly" is just gonna be "Ok, I'm gonna tell you anyways".


That aside, it would really take *effort* to configure your MTA to 
provide TLS as bad as plaintext (e.g. null or export ciphersuites), but 
at that point those attacks are kinda your fault. That applies against 
both passive eavesdropping and active attackers. MUAs might be a tad 
different, but those don't support the worst TLS has to offer anyways. 
The weak stuff that is still enabled would still take a while to attack 
or crack.


I mean, it should be fairly obvious that people won't wait until the 
previous iteration gets utterly demolished before switching to the new 
one, they still hold to some extent. This "purism", if one can call it 
that, has kinda made you miss the original goal and lose perspective of 
future improvements.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Jarland Donnell via mailop]

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 presented with confirmation of a secure connection 
when it isn't secure. 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 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. 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.


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.


On 2022-08-03 16:02, Bastian Blank via mailop wrote:
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:
https://hacks.mozilla.org/2019/05/tls-1-0-and-1-1-removal-update/


Firefox does not speak MTA, so you are talking about a completely
different problem.  MTA is oportunistic TLS, web is required TLS.

Bastian

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Bastian Blank via mailop]

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:
> https://hacks.mozilla.org/2019/05/tls-1-0-and-1-1-removal-update/

Firefox does not speak MTA, so you are talking about a completely
different problem.  MTA is oportunistic TLS, web is required TLS.

Bastian

-- 
Phasers locked on target, Captain.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Slavko via mailop]

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 upstream, etc. If you are 
>using an insecure SSL protocol/cipher, the transactions cannot be called 
>secure. Period.

Sure, any hop between client and server can be bad actor, the
same applies to any hop between two servers. Not only due
MTM attack, but for spying too, eg. to prepare targeted attack
or steal something (that is why EtE encryption exists) or
even message modification. And that is where on particular
cipher matter. If it is weak, it cannot provide that level security,
as one can expect (hide content from other). If it is not
considered as secure, it is insecure, and no one can rely on it,
dot.

Or is here someone who will consider Base64 encoded message
as secured, because its content is hidden for most of people?

And for mentioned HTTP example -- it describes only really
simple client-server communication, but when more complicated
setup is used, whete web server acts as reverse proxy for some
app (or other server), the HTTP becomes exatly as SMTP in that,
that client cannot know how "server" to server communication
was done in behind...

Of course, cipher's security is only one part of play, but that
doesn't matter in TLS version selection.

BTW, Jarland, thanks for your words, that insecure ciphers
are worse than plain text, i agree with you.

regards
Slavko
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Jaroslaw Rafa via mailop]

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). Period.
> 
> 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 website and there is no one in between, what exactly is the
> point of SSL at all? Is it merely cosmetic in nature? Why do we have secure
> connections to anything if an old-school trust model is sufficient?

You totally didn't understand me.

I never said the client is plugged directly into the server and there's no
one in between. I'm talking exactly about SSL.

If you have a strong SSL connection from browser to server, *and* you have a
verified certificate, *and you trust the certificate issuer*, *and you trust
the server* (that it doesn't use your data for any other purpose that it
claims to - for example does not send a copy of your otherwise secure and
encrypted communication to some third party), then your connection is secure.

This is *not* the case of email. First, you *don't* have a direct connection
from sending application to receiving application - the message goes through
one or more servers on its way. If there is only one server (ie. sender and
recipient have e-mail accounts on the same server), the clients connect to
the server securely *and* you trust the server operator that they don't read
your messages, then - and only then - your email is secure.

If sender's and receiver's email accounts are on different servers, then
email is insecure by design :). You don't have, neither as sender nor as the
receiver, control over how one server connects to the other and if it uses
any intermediate servers in between. You don't have control over what
operators of these servers do with your messages. So if you want email to be
secure, you must encrypt it before it leaves your email client (I'm talking
here of content encryption, not in-transit encryption like SSL) and it must
stay encrypted all the time, until receiver decrypts it when it is already
in their mail client.

So any speculations about more or less secure TLS used on MTA-to-MTA
connections make no sense as there is much more happening in process of
email transit than one simple connection (as it is in case of HTTPS).

Plus, you seem to ignore the fact that there is no such thing as "secure" or
"insecure". Nothing is 100% secure and you can only say about things being
less or more secure. Everything is the matter of potential risk versus
protection measures involved - in fact, balancing these two is the essence
of the entire art of security :). As you have yourself pointed out, even a
plaintext connection is secure if the risk is minimal, ie. you know that
there's no one in between.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Simon Arlott via mailop]

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 secure and it isn't, 
> that's on the client. So why is anyone doing this? You guys are replying 
> to me like I'm some insane outlier here by suggesting that there's merit 
> to a basic security practice of not allowing insecure ciphers/protocols, 
> and I'm sitting here staring at my screen saying "How can anyone call 
> themselves a professional and seriously argue against that?" Just cards 
> on the table here, that's the perspective on this side.

The problem here is the fallback to plaintext. Web browsers don't
fallback to plaintext without user intervention. There is no user to
intervene in email.

I support disabling TLS 1.0/1.1 but there is a trade-off to be made,
especially when the remote client may not even be verifying your
certificate despite using TLS 1.2.

The same issues arise with older ciphers and support for MD5/SHA1.

If there was a viable downgrade attack that could make a TLS 1.2 client
[that isn't providing a client certificate] use TLS 1.0/1.1 then that
would be a good reason for disabling TLS 1.0/1.1 support.

-- 
Simon Arlott
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Bastian Blank via mailop]

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, etc. If
> you are using an insecure SSL protocol/cipher, the transactions cannot be
> called secure. Period.

Secure is not the correct term, verified would be it.  But to establish
a verified connection in the context of SMTP you need DANE.  And with
DANE you can enforce proper current protocols.

However you still did not show how plaintext would be more secure then
old TLS.

But anyway:
Plaintext is easily defeated by passive eavesdropping.

Old TLS even without verification requires at least active MITM.  Aka it
is more secure.

Bastian

-- 
... The prejudices people feel about each other disappear when they get
to know each other.
-- Kirk, "Elaan of Troyius", stardate 4372.5
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Grant Taylor via mailop]

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 by the very nature of striving for something, sometimes you will fail.

Are all of these security experts and corporations just playing 
a game with TLS versions,


Not all of them.  But I do completely believe that at least some of them 
are playing a game with TLS versions.


Aside:  Years ago I saw -- what I think was -- a Far Side cartoon about 
new monitor standards / capability.  I can't quickly find it, but 
chasing the latest and greatest seems apropos to the conversation.



or is there perhaps something to this security practice?


There is something to it for some situations.

There are a lot of things that can be done to build a house that's 
(effectively) fire proof, e.g. out of concrete.  But there's even more 
that can be done to reduce the risk of fire even more, e.g. pouring 
1,000 foot radius concrete circle around said concrete house.  What is 
proper is situationally dependent.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Grant Taylor via mailop]

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 website and there is no one in between, what 
exactly is the point of SSL at all? Is it merely cosmetic in nature? Why 
do we have secure connections to anything if an old-school trust model 
is sufficient?


TEMPEST?  }:-)

Making sure that someone else can't snoop the traffic between the two 
adjacent systems.


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, 
etc. If you are using an insecure SSL protocol/cipher, the transactions 
cannot be called secure. Period.


Aside:  What is "secure"?  --  IMHO "secure" is an ambiguous 
intersection between privacy and / or authenticity.


I can be sure that data is authentic, as in unmodified, by using a null 
cipher and / or IPsec AH.  I can ensure that data is private using any 
sufficiently strong cipher and / or IPsec ESP.  Even clear text HTTP 
over a VPN is private.


As Brandon said, "Everything in security depends on your threat model.".

If I'm concerned about a toddler learning a passcode to the iPad, I'll 
walk to the corner and cup my hand over my mouth as I share it.  If I 
need to protect the intellectual property of my employer, I'm going to 
do a LOT more.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Jarland Donnell via mailop]

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 SSL 
version they're using. So if the site says it's secure and it isn't, 
that's on the client. So why is anyone doing this? You guys are replying 
to me like I'm some insane outlier here by suggesting that there's merit 
to a basic security practice of not allowing insecure ciphers/protocols, 
and I'm sitting here staring at my screen saying "How can anyone call 
themselves a professional and seriously argue against that?" Just cards 
on the table here, that's the perspective on this side.


The idea that a mail server operator should be treated as more capable 
and intentional than an end user doesn't take into account how many end 
users are mail server operators.



On 2022-08-03 14:51, Jaroslaw Rafa via mailop wrote:

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 it as isn't as important as what the other party logs it 
as.
Sure if it were within spec to be able to return a message that the 
other
MTA logs as "Secure but not really secure" that would be a great 
middle
ground, the problem is that the other MTA accepts it and logs it as 
secure,


Like that?

Aug  3 21:39:57 rafa postfix/smtpd[17973]: Anonymous TLS connection
established from mx.mailop.org[91.132.147.157]: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

You clearly see what TLS version and what ciphers were used. So you 
know if

it was "secure" in your opinion or not.

But take into account that most of these connections log as "Anonymous 
TLS"
which means there is no client certificate presented nor verified. So 
you
don't know whether the client connecting to you really is what it 
claims to
be. MITM is perfectly possible. I would say that in that case the 
quality of

cipher used is less important.

And if you configure your server to *require* remote servers to present
certificates when connecting to port 25, you would probably cut off 
most of

your incoming e-mail.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Grant Taylor via mailop]

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 that's even as cut and dry as we'd like to hope. 
Sanctioned TLS intercepting proxies tend to violate your statement.


I agree with everything else that you said.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Grant Taylor via mailop]

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 once upon a time the most secure thing.  Hindsight shows 
that it's not /secure/.


the least secure line is the one that says "I am secure" and 
isn't.


That gets into the philosophical discussion ~> debate of which is the 
least trust worthy, the thing that says that it's not, or the thing that 
says it is when it really isn't.


I admit there is a measure of a false sense of security.  But that's a 
perception issue.


From an attacker's point of view, there is effectively no difference in 
something in plain text and something in ROT13.


This might sound confusing because most people would think "The least 
secure line is the one that says 'I am not secure'" instead. But 
when you say "This is not a secure line" you know for sure that 
both parties fully understand that it isn't secure. Where as if 
you say "This is a secure line" and it isn't because the other 
party either doesn't know what they're doing or is the victim of 
a downgrade attack (through whatever attack vector that came from) 
then the other party walks away saying "I transmitted secure data" 
and to them it's over. Playing either role in that situation is bad, 
but being the intelligent admin who cares none for the other guy is 
worse than just saying up front: "This isn't secure, plan accordingly."


Monkey in the middle is still a problem on contemporary, supposedly 
secure, protocols.  The monkey can even be outside of the TLS stream.  I 
can configure a mail server to copy messages that were transmitted to & 
from it via TLS 1.3 with your choice of ciphers.


So ... with that in mind, I feel like your statement about TLS 1.3 is 
equally as susceptible as TLS 1.0 in that regard.


Then there's still the problem of me using a camera to take a picture of 
the time limited / self destruct message that was sent using the 
absolute best security possible.  Again, the best channel security falls 
down with problems at either end.


I feel like you are more in the philosophical domain and pushing back 
into the technical domain trying to enhance security.  I think that's 
laudable.  But I personally don't think ~> believe that "plain text to 
be more secure than insecure SSL".




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Jarland Donnell via mailop]

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 
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 website and there is no one in between, what 
exactly is the point of SSL at all? Is it merely cosmetic in nature? Why 
do we have secure connections to anything if an old-school trust model 
is sufficient?


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, 
etc. If you are using an insecure SSL protocol/cipher, the transactions 
cannot be called secure. Period.


On 2022-08-03 14:26, Jaroslaw Rafa via mailop wrote:

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 
people
would think "The least secure line is the one that says 'I am not 
secure'"
instead. But when you say "This is not a secure line" you know for 
sure that
both parties fully understand that it isn't secure. Where as if you 
say
"This is a secure line" and it isn't because the other party either 
doesn't
know what they're doing or is the victim of a downgrade attack 
(through

whatever attack vector that came from) then the other party walks away
saying "I transmitted secure data" and to them it's over.


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.

When sending e-mail, the sender has absolutely no knowledge nor 
influence
whether the intermediate servers will use plain text, less secure or 
more
secure TLS algorithms, and whether the server operators won't intercept 
your
email, which they are fully capable of, regardless what TLS variant is 
used.
With e-mail, neither sending nor receiving party knows if it is secure 
or
not. So if you want "perfect" security, you must always assume e-mail 
is

inherently insecure, unless you are exchanging e-mail within a single
server, clients connect to that server securely and you trust the 
server
operator. If you want secure e-mail, use end-to-end encryption with 
PGP,

S/MIME or similar. Period.

So there's a BIG difference between disabling insecure algorithms on 
HTTPS
client-to-server connection (or e-mail client to e-mail server 
connection)
and on opportunistic TLS between e-mail servers. In that case I agree 
that
some security - even if not perfect - is better than no security at 
all, ie.

weak TLS transmission is better than plaintext transmission.

Security is not all or nothing, security is a spectrum and the amount 
of
security needed should always match the estimated risk. Risk assessment 
is
an essential part of implementing any security. In our case, the risk 
of
plaintext communication being intercepted is obviously larger than the 
risk
of (even weakly) encrypted communication being intercepted. The latter 
case
requires more effort from the potential attacker, which may be not 
worth the

result.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Jaroslaw Rafa via mailop]

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 it as isn't as important as what the other party logs it as.
> Sure if it were within spec to be able to return a message that the other
> MTA logs as "Secure but not really secure" that would be a great middle
> ground, the problem is that the other MTA accepts it and logs it as secure,

Like that?

Aug  3 21:39:57 rafa postfix/smtpd[17973]: Anonymous TLS connection
established from mx.mailop.org[91.132.147.157]: TLSv1.2 with cipher
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

You clearly see what TLS version and what ciphers were used. So you know if
it was "secure" in your opinion or not.

But take into account that most of these connections log as "Anonymous TLS"
which means there is no client certificate presented nor verified. So you
don't know whether the client connecting to you really is what it claims to
be. MITM is perfectly possible. I would say that in that case the quality of
cipher used is less important.

And if you configure your server to *require* remote servers to present
certificates when connecting to port 25, you would probably cut off most of
your incoming e-mail.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Michael Rathbun via mailop]

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 likely point of interception of email
transactions by a hostile party is in the local network, where clients
communicate in the clear, for the most part, and configuration audit trails
are slim.  Whether something foreign could be wiresharking your mail server is
a different discussion.

Large-scale MITM attacks present some interesting engineering problems, above
the doubtful ROI.  Correspondents who must exchange information that should
not be disclosed to a third party already know how to avoid an inherently
insecure channel.

mdr
-- 
  If you have a system set up where a single person can cause an
  extinction level event, it's time to re-examine that system.
  -- Florence  (Freefall)

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Jarland Donnell via mailop]

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 within spec to be able to return a message that the 
other MTA logs as "Secure but not really secure" that would be a great 
middle ground, the problem is that the other MTA accepts it and logs it 
as secure, and by virtue of the transaction happening at all we can 
pretty well assume that it doesn't fall within the intentions of the 
other party. After all, if they didn't want secure email it was much 
easier to not. If they did, and they're doing so insecurely, that is a 
problem. That it is their problem alone goes back to the whole reasoning 
behind the basic security practices of removing insecure 
protocols/ciphers be it client or server level, the existence of the 
connection shows that the other party is either compromised or 
incapable. At that point the same risks exist as they would for an end 
user visiting a secure site with Firefox, who fully understands their 
duty to not show that lock icon when it isn't really secure.



Your server doesn't really report to the other server that the
connection is secure, only that it could be established. The other
server may have decided that it's secure based on its protocol and
cipher support.


And again, this is where the basic security practice comes in. If that 
logic was sound, then it is a travesty that software and OS developers 
have removed old SSL protocols and ciphers, is it not? Why did they 
remove them? I'm not trying to lean on them to say "They did it so it's 
the way." I'm trying to add legitimacy to say "I'm not just some crazy 
guy shouting from the corner, look at how many respected people 
understand why allowing insecure protocols and ciphers is a bad security 
practice." The most reasonable sounding counter point being that they 
are servers, not clients. But I think that falls apart pretty quickly 
when the server is Bob's DigitalOcean MailInABox turnkey appliance. 
Running a mail server doesn't mean you always make informed choices, or 
that you're always aware of risks, in the same way that a desktop user 
staring at their web browser can't be expected to always be informed or 
aware of all risk either.


Anyway, good topic.

On 2022-08-03 14:02, Simon Arlott via mailop wrote:

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 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.


insecure, only one of the two involves your server negotiating and
reporting to the third party that you are accepting it over a secure


Your server doesn't really report to the other server that the
connection is secure, only that it could be established. The other
server may have decided that it's secure based on its protocol and
cipher support.


connection. Which is basically a lie. Plain isn't a lie, and that's
worth something.


Having said that, I'm currently accepting TLS 1.0/1.1 connections as a
server with a restricted cipher list but requiring TLS 1.2 as a client
(which will then fallback to plaintext).


Cipher selection is another issue... I have come across one 
organisation

that had configured their TLS-only servers to only support the x25519
curve when using ECDHE - and my cipher configuration requires 
DHE/ECDHE.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Jaroslaw Rafa via mailop]

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 people
> would think "The least secure line is the one that says 'I am not secure'"
> instead. But when you say "This is not a secure line" you know for sure that
> both parties fully understand that it isn't secure. Where as if you say
> "This is a secure line" and it isn't because the other party either doesn't
> know what they're doing or is the victim of a downgrade attack (through
> whatever attack vector that came from) then the other party walks away
> saying "I transmitted secure data" and to them it's over.

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.

When sending e-mail, the sender has absolutely no knowledge nor influence
whether the intermediate servers will use plain text, less secure or more
secure TLS algorithms, and whether the server operators won't intercept your
email, which they are fully capable of, regardless what TLS variant is used. 
With e-mail, neither sending nor receiving party knows if it is secure or
not. So if you want "perfect" security, you must always assume e-mail is
inherently insecure, unless you are exchanging e-mail within a single
server, clients connect to that server securely and you trust the server
operator. If you want secure e-mail, use end-to-end encryption with PGP,
S/MIME or similar. Period.

So there's a BIG difference between disabling insecure algorithms on HTTPS
client-to-server connection (or e-mail client to e-mail server connection)
and on opportunistic TLS between e-mail servers. In that case I agree that
some security - even if not perfect - is better than no security at all, ie.
weak TLS transmission is better than plaintext transmission.

Security is not all or nothing, security is a spectrum and the amount of
security needed should always match the estimated risk. Risk assessment is
an essential part of implementing any security. In our case, the risk of
plaintext communication being intercepted is obviously larger than the risk
of (even weakly) encrypted communication being intercepted. The latter case
requires more effort from the potential attacker, which may be not worth the
result.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Simon Arlott via mailop]

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 be trusted when it's from the headers added by your last 
> MTA in the transaction, everything between can't be verified.

That's not really something the MUA can easily do... all of my incoming
email arrives using TLS because there's an internal hop.

-- 
Simon Arlott
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Simon Arlott via mailop]

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 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.

> insecure, only one of the two involves your server negotiating and 
> reporting to the third party that you are accepting it over a secure

Your server doesn't really report to the other server that the
connection is secure, only that it could be established. The other
server may have decided that it's secure based on its protocol and
cipher support.
 
> connection. Which is basically a lie. Plain isn't a lie, and that's 
> worth something.

Having said that, I'm currently accepting TLS 1.0/1.1 connections as a
server with a restricted cipher list but requiring TLS 1.2 as a client
(which will then fallback to plaintext).


Cipher selection is another issue... I have come across one organisation
that had configured their TLS-only servers to only support the x25519
curve when using ECDHE - and my cipher configuration requires DHE/ECDHE.

-- 
Simon Arlott
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Jarland Donnell via mailop]

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 accepted mechanism to force encryption in the first place.


Why can't an MTA verify a certificate? Postfix seems to do certificate 
verification, for example: 
https://www.postfix.org/TLS_README.html#server_vrfy_client


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 be trusted when it's from the headers added by your last 
MTA in the transaction, everything between can't be verified.


On 2022-08-03 13:39, Joel M Snyder 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.
  What's the common consensus in the mail community about this 
currently?


I don't really see the point, unless the goal is to marginally improve
security while causing compatibility issues with other folks on the
Internet.

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 accepted mechanism to force encryption in the first place.

So this change would edge it up in one direction while leaving all of
the gaping holes untouched.  And, absolutely, you would cause
compatibility issues with some folks.  So the end result is going to
be no increase in security and a decrease in interoperability.

MTA-MTA encryption is like locks on doors: they keep honest people
honest, and bored people from looking at your correspondence.  It's
nice to have and certainly better than having every bit of email
whizzing around in plaintext (maybe... as I wrote that I decided I'm
not so sure), but you're just asking for trouble if you start to get
all secret-agent-man secure.

Note that this is NOT a bad idea for anyone doing IMAP or SMTP
submission---those obviously are places where strong encryption is
invaluable and recent versions of TLS are required to exercise your
standard duty of care.  But MTA-MTA... I'm going to go with "meh" on
that one.

jms

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Joel M Snyder 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.
  
What's the common consensus in the mail community about this currently?


I don't really see the point, unless the goal is to marginally improve 
security while causing compatibility issues with other folks on the 
Internet.


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 accepted mechanism to force encryption in the first place.


So this change would edge it up in one direction while leaving all of 
the gaping holes untouched.  And, absolutely, you would cause 
compatibility issues with some folks.  So the end result is going to be 
no increase in security and a decrease in interoperability.


MTA-MTA encryption is like locks on doors: they keep honest people 
honest, and bored people from looking at your correspondence.  It's nice 
to have and certainly better than having every bit of email whizzing 
around in plaintext (maybe... as I wrote that I decided I'm not so 
sure), but you're just asking for trouble if you start to get all 
secret-agent-man secure.


Note that this is NOT a bad idea for anyone doing IMAP or SMTP 
submission---those obviously are places where strong encryption is 
invaluable and recent versions of TLS are required to exercise your 
standard duty of care.  But MTA-MTA... I'm going to go with "meh" on 
that one.


jms

--
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Senior Partner, Opus One   Phone: +1 520 324 0494
j...@opus1.comhttp://www.opus1.com/jms

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Jarland Donnell via mailop]

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 website" in Firefox when it isn't. 
By the very fact alone that a remote SMTP server is connecting to yours 
over TLS 1.0 we can reasonably deduce that the person on the other side 
is not to be considered to be okay. Either they don't know how to manage 
their server or they are the victim of a server side downgrade attack. 
You can't only react to security you have to be proactive, and just 
because I've never seen someone be the victim of a downgrade attack on a 
Postfix install doesn't mean that it isn't the best security practice to 
protect against that.


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? Are all of these security 
experts and corporations just playing a game with TLS versions, or is 
there perhaps something to this security practice?


On 2022-08-03 13:16, Bill Cole via mailop wrote:

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 of the room and cup your hand around the
mouth piece?  Even questionable security is better than no security in
many cases.

No, it isn't. It isn't security at all. If you call someone and tell 
them you need their SSN and they ask "Is this a secure line?" If it's 
not, you're supposed to say "No." You're not supposed to say "This is 
a secure line" and leave unstated the subtext of "If you didn't do 
your research to know why this isn't a secure line, it's your 
problem." It's on you when you say "Yes" to "Is this secure?" when it 
isn't secure.


But that's not at issue with allowing TLS 1.0 and 1.1 in SMTP. Clients
aren't "told" a session is "secure," they *negotiate* a session's
specific security features in a deterministic manner. Presumably a
client that can't do TLS 1.2 or 1.3 has no expectation of any better
security than they can get with whatever TLS versions they can do.

If you believe that either of those older versions of TLS is as
vulnerable as plain text, please specify why. As far as I am aware,
the only problems with them are inclusion of some weak (but not
trivially so) ciphers by default and attacks that can't work against a
typical SMTP server.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Grant Taylor via mailop]

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 TLS 
library to application code, allowing connections to be upgraded from 
clear to encrypted produces many more bugs than just requiring the 
connection to be secure from the start.


Interesting.  I see this as potentially untested / less well tested code 
paths which are in and of themselves additional attack surface that 
doesn't exist when implicit TLS is used.


There is also the elephant in the room that servers must properly be 
configured to require explicit TLS.  Something that may be overlooked.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Jarland Donnell via mailop]

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 
because most people would think "The least secure line is the one that 
says 'I am not secure'" instead. But when you say "This is not a secure 
line" you know for sure that both parties fully understand that it isn't 
secure. Where as if you say "This is a secure line" and it isn't because 
the other party either doesn't know what they're doing or is the victim 
of a downgrade attack (through whatever attack vector that came from) 
then the other party walks away saying "I transmitted secure data" and 
to them it's over. Playing either role in that situation is bad, but 
being the intelligent admin who cares none for the other guy is worse 
than just saying up front: "This isn't secure, plan accordingly."


On 2022-08-03 12:59, Grant Taylor via mailop wrote:

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 given root to anything.


First, I didn't admit that I don't understand why it's a good security
practice to disable insecure SSL protocols and ciphers.  I very well
understand why insecure SSL protocols and ciphers should be abandoned.

Second, I'm okay admitting things.  I've found that admitting my
faults garners others trust in my statements when something is not the
case.

Third, I asked for clarification about or pointers supporting your
"well respected security practice to consider plain text to be more
secure than insecure SSL" statement.

Specifically "plain text to be more secure than insecure SSL".



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Bill Cole via mailop]

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 of the room and cup your hand around the
> mouth piece?  Even questionable security is better than no security in
> many cases.
>
> No, it isn't. It isn't security at all. If you call someone and tell them you 
> need their SSN and they ask "Is this a secure line?" If it's not, you're 
> supposed to say "No." You're not supposed to say "This is a secure line" and 
> leave unstated the subtext of "If you didn't do your research to know why 
> this isn't a secure line, it's your problem." It's on you when you say "Yes" 
> to "Is this secure?" when it isn't secure.

But that's not at issue with allowing TLS 1.0 and 1.1 in SMTP. Clients aren't 
"told" a session is "secure," they *negotiate* a session's specific security 
features in a deterministic manner. Presumably a client that can't do TLS 1.2 
or 1.3 has no expectation of any better security than they can get with 
whatever TLS versions they can do.

If you believe that either of those older versions of TLS is as vulnerable as 
plain text, please specify why. As far as I am aware, the only problems with 
them are inclusion of some weak (but not trivially so) ciphers by default and 
attacks that can't work against a typical SMTP server.


-- 
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

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Andrew C Aitchison via mailop]

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 are times that I question the actual security differences between 
implicit TLS verses /requiring/ explicit TLS.  E.g. configuring the 
submission port (587) to refuse to do anything without first issuing 
STARTTLS.


What you mean by "actual security differences" may be significant.

IIUC the "No STARTTLS" people have found that, when connecting a TLS 
library to application code, allowing connections to be upgraded from 
clear to encrypted produces many more bugs than just requiring the 
connection to be secure from the start.


--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Grant Taylor via mailop]

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 given root to anything.


First, I didn't admit that I don't understand why it's a good security 
practice to disable insecure SSL protocols and ciphers.  I very well 
understand why insecure SSL protocols and ciphers should be abandoned.


Second, I'm okay admitting things.  I've found that admitting my faults 
garners others trust in my statements when something is not the case.


Third, I asked for clarification about or pointers supporting your "well 
respected security practice to consider plain text to be more secure 
than insecure SSL" statement.


Specifically "plain text to be more secure than insecure SSL".



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Jarland Donnell via mailop]

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, it isn't. It isn't security at all. If you call someone and tell 
them you need their SSN and they ask "Is this a secure line?" If it's 
not, you're supposed to say "No." You're not supposed to say "This is a 
secure line" and leave unstated the subtext of "If you didn't do your 
research to know why this isn't a secure line, it's your problem." It's 
on you when you say "Yes" to "Is this secure?" when it isn't secure.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Jarland Donnell via mailop]

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 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 or reported as a secure connection.


What‽‽‽

Please elaborate.  Please point to more documentation related to this
respected security practice.

Both being insecure, only one of the two involves your server 
negotiating and reporting to the third party that you are accepting it 
over a secure connection. Which is basically a lie. Plain isn't a lie, 
and that's worth something.

I don't see how considering "not the best security" as more secure
than "no security" is a lie in any way, shape, or form.

I feel like this is a case of anything less than perfect is not good
enough and thus a waste of time.  --  I often see such sentiments
causing people to abandon give up on any from of security and
continuing without any security at all.

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.



___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Brandon Long via mailop]

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 or reported as a secure connection.
>
> What‽‽‽
>
> Please elaborate.  Please point to more documentation related to this
> respected security practice.
>
> > Both being insecure, only one of the two involves your server
> > negotiating and reporting to the third party that you are accepting
> > it over a secure connection. Which is basically a lie. Plain isn't
> > a lie, and that's worth something.
> I don't see how considering "not the best security" as more secure than
> "no security" is a lie in any way, shape, or form.
>
> I feel like this is a case of anything less than perfect is not good
> enough and thus a waste of time.  --  I often see such sentiments
> causing people to abandon give up on any from of security and continuing
> without any security at all.
>
> 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.
>

Everything in security depends on your threat model.

If the threat model is people who can tap the phone, then it doesn't matter
your
volume or location when you speak.

For the average user, the threat model may be someone overhearing you by
chance,
and so any encryption is an improvement.

For some users, the threat model is someone who can break lower encryption
or maybe
even force the servers to negotiate a worse encryption level that they can
break.

Fallback to plain text is the Achilles heel, of course... but some systems
have policies
requiring encryption... of course, they could just require encryption that
meets a
certain level as well... (having just had to plumb the tls version of a web
request through
a wide variety of services to enforce this requirement on a per-user basis,
painfully
aware...)

There are also various certification requirements which have rules about
which ssl
versions you allow, if you want government contracts or some types of
financial ones.
They're often couched in ways that make them seem specific to http
services, but
applying them to other services may depend on your auditor or implementor.

Anyways, I'm surprised to see that Google still allows 1.0 and 1.1, I
remember
disabling support for SSLv2/3 years ago, but I guess the numbers here are
still
high and they haven't had enough push for it yet.  I wouldn't be surprised
if
the require tls policy has a version limit on it since almost any customer
that needs
a require tls policy would also need to restrict it to 1.2+, but I didn't
look that hard at it.

Brandon
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Grant Taylor via mailop]

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 differences between 
implicit TLS verses /requiring/ explicit TLS.  E.g. configuring the 
submission port (587) to refuse to do anything without first issuing 
STARTTLS.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Grant Taylor via mailop]

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 point to more documentation related to this 
respected security practice.


Both being insecure, only one of the two involves your server 
negotiating and reporting to the third party that you are accepting 
it over a secure connection. Which is basically a lie. Plain isn't 
a lie, and that's worth something.
I don't see how considering "not the best security" as more secure than 
"no security" is a lie in any way, shape, or form.


I feel like this is a case of anything less than perfect is not good 
enough and thus a waste of time.  --  I often see such sentiments 
causing people to abandon give up on any from of security and continuing 
without any security at all.


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.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Jarland Donnell via mailop]

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 plain text 
connection isn't logged or reported as a secure connection. Both being 
insecure, only one of the two involves your server negotiating and 
reporting to the third party that you are accepting it over a secure 
connection. Which is basically a lie. Plain isn't a lie, and that's 
worth something.


I get by alright while blocking insecure protocols and ciphers. Every 
now and then I'll get a laugh because some small "security" company will 
refuse to deliver mail to the servers while demanding to only speak over 
insecure protocols/ciphers.

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Slavko via mailop]

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 the common consensus
> in the mail community about this currently? 

I do not know how community, but i have for 2-3 years already this
(GnuTLS):

-VERS-TLS1.0:-VERS-TLS1.1:-RSA:-DHE-RSA:-GROUP-DH-ALL

In other words, i had disabled TLS1.0, TLS1.1, pure RSA and DHE. I did
check logs for last month and i see only 5 (five) incomming errors with
illegal or unsupported TLS version, all from suspicious hosts (by first
look on PTR)...

I have allowed TLS1.0 and TLS1.1 for outgoing MTA connections, but i
have no that connections in last time logged, but my outgoing mails
is on very low rate and mostly to the same hosts, thus that is not
representative at all.

The reason of this asymmetric settings is, that i decide to use
encrypted delivery even with old TLS versions (over PLAIN), as it is my
responsibility. When other side (MTA) decide do not support modern
TLS and delivers message in PLAIN, it is their responsibility, not
my one. If they decide do not support modern TLS and do not deliver
in PLAIN, it is again their decision.

Similar (even more strict) TLS settings i have on my MSA, and there are
problems with unsupported TLS version only from cracking attempts and
all my clients are able to connect with modern TLS. I provide **only**
tcp/465 for MSA from time, when it was standardized by RFC, while
even in that time all my clients was already using it.

The port 25 for MSA was deprecated years ago, and tcp/587 is
standardized as fallback only now. IMO here is very simple way to
notify clients that port 25 is not available for them -- do not
provide AUTH over it or deny AUTH with some informative message, soon
or later they will notice it (or will notice, that they cannot login).

It was more years ago, but i meet (big) ISP, which (i guess) used proxy
on port 25 which filtered STARTTLS EHLO response (Cisco ASA?) and thus
all SMTP connection was in PLAIN... I am happy, that we (my employer) is
not using it anymore.

regards

-- 
Slavko
https://www.slavino.sk


pgpKAACR4qa7J.pgp
Description: Digitálny podpis OpenPGP
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Andrew C Aitchison via mailop]

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 community about this currently?

It's already been disabled for our customers towards fx. imap and
smtp, and we all agree those pesky old versions should be phased
out, sooner rather than later, but have you also disabled it for MTA
to MTA communication as well or are you still considering it? And
what scenarios are currently holding you back?


I think I see the argument for dropping TLS 1.0 and 1.1 but keeping PLAIN,
in that the TLS libraries are simpler, although I suspect that
the lean/clean implementations are v1.3 only.


And what about PLAIN - do you still allow that as the fallback
option or are you also considering disabling that?


Last time I heard, many sites did not verify the authenticity of the
certificate. Has that improved with the rollout of DANE and MTA-STS ?
I suspect that there are enough sites that do not yet support both in
both directions that interoperability would suffer if this was widely
enforced.

As I understand it, it is unusual for the server to require an
authenticated client certificate. Does that matter to you ?

If you subscribe to "No STARTTLS" https://nostarttls.secvuln.info/
and drop PLAIN, you have retired port 25. I believe there are ways
to signal that clients should use another port on your server,
but I don't remember the details and don't know how well supported they are.

I guess that it *is* time to start measuring these things, but there
are many cases (mailing lists for one) that do not need encryption, so
I do not think most sites should enforce PLAIN.
Some sites might however wish to include this when evaluating
the reputation of an individual message.

Tobias Fiebig commented:

Side note: I recently ran into a security research institute with
whom I could not agree on ciphers with the OpenSMTPd default cipher
list on my side… their choices were just a tad dusty…


Long ago I has a support ticket from a user visiting a four letter 
national security centre complaining that he could not ssh to our department.

Translated, the error message we were giving was "your codes are too old".
That made my day.

--
Andrew C. Aitchison  Kendal, UK
   and...@aitchison.me.uk___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Tobias Fiebig via mailop]

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 will look worse than those 10%, even though we did not 
test that.

 

The methodology we use should be easily adjustable to also test for specific 
version support; However, recruiting a wide sample of people will be difficult. 
What you _could_ do as a large ESP is configuring multiple MXes with the same 
priority and different settings and run a large scale study that way about 
MTA’s preferences without impacting mail delivery. If you are willing to give 
that a shot, I’d be _very_ interested in collaborating.

 

Side note: I recently ran into a security research institute with whom I could 
not agree on ciphers with the OpenSMTPd default cipher list on my side… their 
choices were just a tad dusty…

 

With best regards,

Tobias 

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Taavi Eomäe 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. 
And what about PLAIN - do you still allow that as the fallback option 
or are you also considering disabling that?


Hardening your MTA's TLS configuration and potentially causing TLSv1.0 
and TLSv1.1 clients to fall back to plaintext is counterproductive. The 
first step should really be disabling plaintext.


In parallel to that, if there's a wish to enforce good TLS, how's your 
MTA-STS support? Both incoming and outgoing?



It's already been disabled for our customers towards fx. imap and 
smtp, and we all agree those pesky old versions should be phased out, 
sooner rather than later, but have you also disabled it for MTA to MTA 
communication as well or are you still considering it? And what 
scenarios are currently holding you back?


In theory that's nice, MUAs do tend to be more up-to-date and there 
might be downgrade attacks that this would prevent. *But...*


There's no MUA-STS, most clients are relatively trivially downgrade-able 
(hopefully with /some/ user interaction, but pestering the user tends to 
work). So does that hardening actually help or potentially force some 
old printers (etc.) to stop working or require a plaintext proxy?



[...] pesky old versions should be phased out, sooner rather than 
later [...]


Pesky old versions, what about "new" versions? Do you support TLSv1.3?


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?




Wishing you a good day,
Taavi
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Disabling TLS 1.0 and 1.1 for MTA to MTA communication

[Hans-Martin Mosner via mailop]

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 it.
Disabling support for less secure transport encryption protocols doesn't 
increase security if the senders can then switch to unencrypted transport as a 
fallback.

If you're Google or Microsoft, you might be able to pull that off. Otherwise it 
only works if your users are willing to live with the consequences.

FWIW, rejecting unencrypted connections also does reduce the amount of spam a 
little bit, but it's almost unnoticeable in my experience.

Cheers,
Hans-Martin

3. August 2022 13:34, "Sidsel Jensen via mailop" mailto:mailop@mailop.org?to=%22Sidsel%20Jensen%20via%20mailop%22%20)>
 schrieb:
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 disabled for our customers towards fx. imap and smtp, and we 
all agree those pesky old versions should be phased out, sooner rather than 
later, but have you also disabled it for MTA to MTA communication as well or 
are you still considering it? And what scenarios are currently holding you back?

And what about PLAIN - do you still allow that as the fallback option or are 
you also considering disabling that?

I'm looking forward to read your replies :-)
Kind Regards,
Sidsel Jensen

Architect of Deliverability and Abuse @ Open-Xchange
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop