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] New *.outbound.protection.outlook.com servers without PTR

[Michael Wise via mailop]

Those responsible have been poked. 

Aloha,
Michael.
--
Michael J Wise
Microsoft Corporation| Spam Analysis
"Your Spam Specimen Has Been Processed."
Got the Junk Mail Reporting 
Tool ?

From: mailop  On Behalf Of Vladimir Gabrielescu
Sent: Tuesday, May 22, 2018 3:44 AM
To: Bernhard Schmidt ; mailop@mailop.org
Subject: Re: [mailop] New *.outbound.protection.outlook.com servers without PTR


You are not alone, we've seen this too.


From: mailop > on 
behalf of Bernhard Schmidt 
>
Sent: Tuesday, May 22, 2018 6:41:18 AM
To: mailop@mailop.org
Subject: [mailop] New *.outbound.protection.outlook.com servers without PTR

Hi,

recently (about a week ago) *.outbound.protection.outlook.com started
sending from three new /24 without valid FCrDNS

40.92.73.0/24
40.92.74.0/24
40.92.75.0/24

i.e. EUR04-HE1-obe.outbound.protection.outlook.com (HELO) sending from
40.92.73.10

The /16 is delegated to msft.net

We have added them to the whitelist for scoring, but unfortunately the
whitelist for Greylisting (which is necessary because the servers retry
from different IPs) is FCrDNS based.

Best Regards,
Bernhard

--
Bernhard Schmidt  Netzbetrieb / IPv6 / DNSSEC
Leibniz-Rechenzentrum   Leibniz Supercomputing Centre
Boltzmannstr. 1  D-85748 Garching b. Muenchen
Tel: +49 89 35831-7885 E-Mail/Jabber: 
bernhard.schm...@lrz.de
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] SNDS report issues?

[Krishna Garewal via mailop]

The root cause issue is fixed but data is not backfilled, there’s going to be 
missing data from 17-19th.

From: mailop  On Behalf Of Benjamin BILLON
Sent: Tuesday, May 22, 2018 9:43 AM
To: mailop@mailop.org
Subject: Re: [mailop] SNDS report issues?

May 17 and 19 not clickable from the UI.
18 clickable, but empty.

From data feed, 17 and 19 replying " 204 No Content" HTTP
18 replies " 200 OK"  but empty file

20 and 21 are ok

--

Benjamin Billon

From: mailop > On 
Behalf Of Julie Ralston via mailop
Sent: Tuesday, 22 May, 2018 23:54
To: mailop@mailop.org
Subject: Re: [mailop] SNDS report issues?

I am seeing similar. May 18th missing data and not clickable for 19th. May 20 
and 21 look ok.

From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Annalivia Ford
Sent: Tuesday, May 22, 2018 11:23 AM
To: mailop@mailop.org
Subject: Re: [mailop] SNDS report issues?

+1 on this, though for a few IPs we do see data up to the 20th. Most stop on 
the 16th.
Regards,

Annalivia Ford
Email Services Manager, EMEA
[IBM Cognitive Engagement | Watson Marketing | Watson Commerce | Watson 
Marketing]

[IBM Watson]

Phone: +31 (0)6 53 32 34 44
eMail: annalivi...@nl.ibm.com












From:Marc Bradshaw via mailop 
>
To:mailop@mailop.org
Date:20/05/2018 03:14
Subject:Re: [mailop] SNDS report issues?
Sent by:"mailop" 
>




Hi,

We have been seeing the same thing, nothing since the 16th.


Julie Ralston
Email Deliverability Expert
1001 Cathedral Street
Baltimore, MD 21201
Phone: 410-864-0891
E-Mail: jrals...@pubsvs.com
Website: 
https://pubsvs.com

[www.pubsvs.com]
- Original message -
From: Stefano Bagnara >
To: mailop >
Subject: [mailop] SNDS report issues?
Date: Sat, 19 May 2018 15:00:08 +0200

In my SNDS reports I see May 17th not clickable and May 18 works but it is
empty (No data for specified IPs on this date).
Data until May 16 is OK.

Anyone else confirm this issue?

Stefano

--
Stefano Bagnara
Apache James/jDKIM/jSPF
VOXmail/Mosaico.io/VoidLabs

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

--

  Marc Bradshaw - Deliverability/Abuse at FastMail
  m...@fastmailteam.com | 
@marcbradshaw



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



Tenzij hierboven anders aangegeven: / Unless stated otherwise above:
IBM Nederland B.V.
Gevestigd te Amsterdam
Inschrijving Handelsregister Amsterdam Nr. 33054214
___
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] [EXTERNAL] Re: Disabling TLS1.0 for SMTP

[Brotman, Alexander]

If someone is interested, we could potentially ask Binu if he has newer data 
available.  He had done a presentation on the same data at M3AAWG a few years 
ago.

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast


-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Rohan Sheth
Sent: Tuesday, May 22, 2018 11:06 AM
To: mailop@mailop.org
Subject: [EXTERNAL] Re: [mailop] Disabling TLS1.0 for SMTP

On Tue, 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?

Admittedly a few years old (March 2016) but Yahoo shared some data about TLS 
versions they see: 
https://yahoo-security.tumblr.com/post/141495385400/measuring-smtp-starttls-deployment-quality

Scrolling down to the TLS Session section, it seems at the time they still saw 
a large volume of TLS 1.0. I would guess that it hasn't changed enough that it 
is OK to blanket disable TLS 1.0 today. 

-Rohan

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
___
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

[mailop] New *.outbound.protection.outlook.com servers without PTR

[Bernhard Schmidt]

Hi,

recently (about a week ago) *.outbound.protection.outlook.com started
sending from three new /24 without valid FCrDNS

40.92.73.0/24
40.92.74.0/24
40.92.75.0/24

i.e. EUR04-HE1-obe.outbound.protection.outlook.com (HELO) sending from
40.92.73.10

The /16 is delegated to msft.net

We have added them to the whitelist for scoring, but unfortunately the
whitelist for Greylisting (which is necessary because the servers retry
from different IPs) is FCrDNS based.

Best Regards,
Bernhard

-- 
Bernhard Schmidt  Netzbetrieb / IPv6 / DNSSEC
Leibniz-Rechenzentrum   Leibniz Supercomputing Centre
Boltzmannstr. 1  D-85748 Garching b. Muenchen
Tel: +49 89 35831-7885 E-Mail/Jabber: bernhard.schm...@lrz.de



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