Re: [mailop] Disabling TLS1.0 for SMTP

[Tim Bray]

On 22/05/18 15:47, Al Iverson wrote:
> Are folks disabling TLS1.0 support in SMTP? Our security team has
> asked, but I'm a bit concerned about potential failure cases when
> trying to deliver mail to smaller corporate sites that might be doing
> stuff like requiring TLS but supporting 1.0 onlyis that really
> much of a concern?

Perspective from a small corporate who runs their own mail,

A quick dip in our logs suggests disabling TLS1.0 would cut off a fair
few of our decent customers.  Inbound and outbound.

By the look of it, mainly exchange mailsystems.   A lot of them kind of
IT companies, so not sure whether they would appreciate a call saying
`you need to upgrade`.

Turns out we also have 1 big customer who doesn't support TLS for mail
at all.  Lets see what they say.

Everything else plain text is spam or `newsletters`.


(Certainly my experience of contacting our customers who are using HTTP
API clients that can't talk TLS1.2 has been general indifference.  I'm
hoping when their payments providers cut them off at the PCI deadline, I
can cut them off too.)



I've also been looking at whether we can deploy dmarc.  We've published
SPF and DKIM stuff for years.  But the reports that come back suggest a
lot of our customers doing dodgy mailforwarding.

(there is no easy answer)

Tim



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Disabling TLS1.0 for SMTP

[Renaud Allard via mailop]

On 05/22/2018 04:47 PM, Al Iverson wrote:

Are folks disabling TLS1.0 support in SMTP? Our security team has
asked, but I'm a bit concerned about potential failure cases when
trying to deliver mail to smaller corporate sites that might be doing
stuff like requiring TLS but supporting 1.0 onlyis that really
much of a concern?

Cheers,
Al Iverson



Have you disabled cleartext SMTP and only allow TLS SMTP? If you still 
have cleartext SMTP enabled, there is no point in disabling TLS1.0 
(except flaws that could reveal your keys).


Of course, for submission, disabling TLS1.0 might be interesting, all 
recent devices (2 years old or less) support TLS1.2. And many older ones 
also support it. But it all depends on where your market is.




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Disabling TLS1.0 for SMTP

[Phil Pennock]

On 2018-05-22 at 14:58 -0400, Eric Tykwinski wrote:
> MTA-STS will probably hit more on the valid certificate deal, but it's on the 
> mta-sts record to get the policy.
> DANE just says this certificate is good, could be expired, self-signed, et al 
> as long as it passes the hash.

DANE has two modes: the certificate (or public key) of the server is in
DNS (DANE-EE), and the certificate (or public key) of the CA which
issued the server certificate is in DNS (DANE-TA).

DANE-EE/DANE-TA terminology from RFC 7218.  There's also PKIX-* modes,
but the email-binding spec expressly prohibits those for $reasons.

For DANE-EE, yes: the security is the binding in DNS, and as long as DNS
identifies the certificate presented, you're done.  Plus side: no
hostname verification, etc etc.  Minus side: have to be extremely
careful in how you roll keys, with DNS TTLs and the like all factoring
into how you make changes.

For DANE-TA, no: the CA certificate (which should be presented in the
chain, especially if you're sanely only publishing fingerprints in DNS,
not full certificates) issues the certificate, and all the usual
verification mechanisms have a role.  There are a couple of different
hostnames which might be tried, depending upon the DNSSEC status and
whether CNAMEs are in play; it's complicated because you can have a
DNSSEC-signed zone with TLSA records, where the MX hosts are CNAMEs
(which violates old RFCs but which ~every MTA supports anyway, because
otherwise people would complain that their boss was threatening to fire
them if they couldn't get the mail through) and those CNAMEs point to
unsigned zones.  So I can't easily condense the rules into this email.

RFC 7672 has the full spec for using DANE with SMTP.

Viktor Dukhovni has given a number of presentations on the topic, and
publishes monthly stats on domains with working DANE.  The uptake is
going better than I'd expected.

If you have Golang (1.8+) then a small plug:
  go get go.pennock.tech/smtpdane
to get a query tool; it requires a validating resolver, but otherwise
can be used to probe DNS and your MX hosts and report on status.  Use
`smtpdane -nagios -mx domain.example` to check all the MX hosts for your
domain in NAGIOS-compatible output/exit-codes.  I monitor spodhuis.org
and exim.org using this tool, with `-expect-ocsp` in there too.

-Phil

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Disabling TLS1.0 for SMTP

[Bill Cole]

On 22 May 2018, at 12:24, Andrew C Aitchison wrote:


Also, does the MTA check the name in the certificate ?


Not generally.


I understand that not all do (or didn't until recently)


None do so with significant consequences for failure, unless they really 
want their mail to break on a regular basis.



since you can't always determine what the name should be.


There are actually 3 issues of absent specification involved:

1. What is the correct name to demand? The recipient domain? The name in 
the MX record? The name in the greeting banner?


2. What are the best responses to each of the various modes of 
certificate verification failure?


3. What does a detectable host-level "impersonation" attempt really mean 
for email? Is it possible? Is it meaningful?


Historically, self-signed certs have been the norm for SMTP servers 
because the only real value of TLS for SMTP has been encryption in 
transit, not authentication. The adoption of DANE (and its predicate 
DNSSEC) may change this eventually, but that's not soon.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Disabling TLS1.0 for SMTP

[Bill Cole]

On 22 May 2018, at 11:12, Steve Atkins wrote:

On May 22, 2018, at 7:47 AM, Al Iverson  
wrote:


Are folks disabling TLS1.0 support in SMTP? Our security team has
asked, but I'm a bit concerned about potential failure cases when
trying to deliver mail to smaller corporate sites that might be doing
stuff like requiring TLS but supporting 1.0 onlyis that really
much of a concern?


If you're connecting to an MX that only supports TLS 1.0 and you've
configured your smarthost to not support TLS 1.0 for opportunistic
encryption then it's going to fall back to not using any sort of 
encryption

and sending as plaintext.

TLS 1.0 has it's flaws, but it's better than entirely unencrypted.


True in regards to SSLv3 and "medium strength" ciphers as well for SMTP 
use & threat models. Authenticated submission arguably justifies tight 
control on protocol & cipher strength, but when doing *transport* to and 
from other people's systems the vulnerabilities that exist are largely 
bob-exploitable and/or only available to sophisticated attackers working 
very hard (i.e. spending a lot of money.) If fallback to sending in the 
clear is allowed, the only protocol that all systems should entirely 
disable is SSLv2, and there's not a significant universe of systems that 
won't do TLSv1 but will do SSLv3, so allowing SSLv3 safely is more 
trouble than it could ever be worth.


FWIW, some numbers: across the MXs I wrangle I'm seeing roughly an even 
split inbound between encrypted and cleartext sessions, and a roughly 
even split between TLSv1 and TLSv1.2 for the encrypted sessions with 
TLSv1.1 <0.1%.  Outbound I get >95% TLS connections, of which >12% are 
TLSv1.0 and >83% TLSv1.2, with negligible TLSv1.1. There's substantial 
variance between systems grounded in the idiosyncrasies of mail streams, 
e.g. some bulk/list endpoints don't even try STARTTLS, others only do 
TLSv1.0, etc.


I wouldn't drop TLSv1.0 support because the systems I work with clearly 
still get benefits from that support, but some systems may not have that 
same experience.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Disabling TLS1.0 for SMTP

[Andrew C Aitchison]

On Tue, 22 May 2018, Al Iverson wrote:


Are folks disabling TLS1.0 support in SMTP? Our security team has
asked, but I'm a bit concerned about potential failure cases when
trying to deliver mail to smaller corporate sites that might be doing
stuff like requiring TLS but supporting 1.0 onlyis that really
much of a concern?


As Steve said, disabling TLS 1.0 gives you plain text,
so unless you can reject plain text there is little reason
to reject TLS 1.0.

If you do keep TLS 1.0 for incoming SMTP, check that the certificates 
aren't valid for other services - particularly POP, IMAP and webmail -

where you do disable TLS 1.0, just in case a TLS version of DROWN
shows up.

Also, does the MTA check the name in the certificate ?
I understand that not all do (or didn't until recently)
since you can't always determine what the name should be.

--
Andrew C. Aitchison Cambridge, UK
and...@aitchison.me.uk

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Disabling TLS1.0 for SMTP

[Paul Smith]

On 22/05/2018 15:47, Al Iverson wrote:

Are folks disabling TLS1.0 support in SMTP? Our security team has
asked, but I'm a bit concerned about potential failure cases when
trying to deliver mail to smaller corporate sites that might be doing
stuff like requiring TLS but supporting 1.0 onlyis that really
much of a concern?


Given that email will drop back to unencrypted if it can't be sent using 
encryption, being too enthusiastic at disabling encryption 
protocols/ciphers will probably just mean that messages end up being 
sent totally unencrypted.


So, is it better to send using a weak encryption or no encryption at 
all? Unless the weak encryption discloses things like private keys which 
could compromise the stronger encryption options, then it's usually 
better to use weak encryption rather than none.


Personally, I'd leave TLS 1.0 enabled unless you're also preventing 
unencrypted traffic and know you will only be dealing with people where 
that won't be a problem (eg on an intranet).




--


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://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Disabling TLS1.0 for SMTP

[ml+mailop]

On Tue, May 22, 2018, Steve Atkins wrote:

> If you're connecting to an MX that only supports TLS 1.0 and you've
> configured your smarthost to not support TLS 1.0 for opportunistic
> encryption then it's going to fall back to not using any sort of encryption
> and sending as plaintext.

That depends on the MTA (and its configuration), e.g., sendmail
before 8.16 would not "fall back to not using any sort of encryption
and sending as plaintext."
(it would require "manual" configuration to turn off the use of
STARTTLS).

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Disabling TLS1.0 for SMTP

[Ken O'Driscoll via mailop]

On Tue, 2018-05-22 at 10:47 -0400, Al Iverson wrote:
> Are folks disabling TLS1.0 support in SMTP? Our security team has
> asked, but I'm a bit concerned about potential failure cases when
> trying to deliver mail to smaller corporate sites that might be doing
> stuff like requiring TLS but supporting 1.0 onlyis that really
> much of a concern?

That is a bad idea. There are still enough places using it that blocking it
will just introduce problems, including as Steve mentioned, unnecessary
unencrypted mailstreams.

A grep just told me that the biggest "offenders" on our MX for the last 4
weeks include 2 multinationals, a telco and a certain DMARC related mailing
list that we're all on.

The PCI DSS gave it a reprieve until the end of June this year so maybe
things will change as part of that compliance process.

Ken.

-- 
Ken O'Driscoll / We Monitor Email
t: +353 1 254 9400 | w: www.wemonitoremail.com

Need to understand deliverability? Now there's a book:
www.wemonitoremail.com/book


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Disabling TLS1.0 for SMTP

[Steve Atkins]

> On May 22, 2018, at 7:47 AM, Al Iverson  wrote:
> 
> Are folks disabling TLS1.0 support in SMTP? Our security team has
> asked, but I'm a bit concerned about potential failure cases when
> trying to deliver mail to smaller corporate sites that might be doing
> stuff like requiring TLS but supporting 1.0 onlyis that really
> much of a concern?

If you're connecting to an MX that only supports TLS 1.0 and you've
configured your smarthost to not support TLS 1.0 for opportunistic
encryption then it's going to fall back to not using any sort of encryption
and sending as plaintext.

TLS 1.0 has it's flaws, but it's better than entirely unencrypted.

(If the flaws in TLS 1.0 were really an issue for your use case then
you'd drop the connection and bounce the mail if the remote host
didn't support TLS 1.1. Probably not a useful approach for email.)

Cheers,
  Steve

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Disabling TLS1.0 for SMTP

[Al Iverson]

Are folks disabling TLS1.0 support in SMTP? Our security team has
asked, but I'm a bit concerned about potential failure cases when
trying to deliver mail to smaller corporate sites that might be doing
stuff like requiring TLS but supporting 1.0 onlyis that really
much of a concern?

Cheers,
Al Iverson

-- 
al iverson // wombatmail // miami
http://www.aliverson.com
http://www.spamresource.com

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop