reality-check on 2016 practical advice re: requiring inbound TLS?

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

reality-check on 2016 practical advice re: requiring inbound TLS?

jasonsu
I'm setting up mandatory TLS policy for a couple of private client servers, using

- smtpd_tls_security_level = may
+ smtpd_tls_security_level = encrypt

I started wondering whether it wouldn't be a bad thing to require ALL email delivered to my server, from anywhere, to use TLS.

Reading at

        http://www.postfix.org/TLS_README.html

It warns against doing this.

         You can ENFORCE the use of TLS, so that the Postfix SMTP server announces STARTTLS and accepts no mail without TLS encryption, by setting "smtpd_tls_security_level = encrypt". According to RFC 2487 this MUST NOT be applied in case of a publicly-referenced Postfix SMTP server. This option is off by default and should only seldom be used.

That RFC, though, is from January 1999

         http://tools.ietf.org/html/rfc2487

and afaict has been superceded by

        http://tools.ietf.org/html/rfc3207

from February 2002, which also says

        "A publicly-referenced SMTP server MUST NOT require use of the
         STARTTLS extension in order to deliver mail locally."

It's 14 years later, and a lot's changed in SSL usage.

Are there any later relevant RFCs that change this advice against forced TLS?

Regardless of RFC, in today's "SSL everywhere" atmosphere, is this still good, practical advice?

I've turned on smtpd_tls_loglevel=1, and will watch for awhile on my own servers.

What do you 'real world' Postfix admins see/do these days?

Jason
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

lists@lazygranch.com
Per the DROWN mitigation, I stopped allowing sslv2 and sslv3, so I made it a point to read the headers and look for encryption issues.

My conclusion is there is always "that one guy" that doesn't use encryption. In my case, literally one guy. Not being able to get his "regular" email to work, I got him to switch to gmail. ‎

This is on my personal server. If you have customers, then each customer can have that "one guy", so it depends on how much time you want to sink into getting a third party to encrypt. 

I also made it a point to look for use of SPF and DKIM. Excluding the spammers that got through, nearly every user had both SPF and DKIM, but not all. One lacking SPF is a new business partner. The account without DKIM was a commercial vendor. My point here was I had considered setting up policies to reject email that didn't have both SPF and DKIM, but doing a survey realized there would be real situations where legitimate email would not get through.  One person I know uses pobox.com, and that fails SPF. 

I think policing everyone's email set up will lead to a lot of busy work. 



  Original Message  
From: [hidden email]
Sent: Saturday, April 9, 2016 8:47 AM
To: [hidden email]
Subject: reality-check on 2016 practical advice re: requiring inbound TLS?

I'm setting up mandatory TLS policy for a couple of private client servers, using

- smtpd_tls_security_level = may
+ smtpd_tls_security_level = encrypt

I started wondering whether it wouldn't be a bad thing to require ALL email delivered to my server, from anywhere, to use TLS.

Reading at

http://www.postfix.org/TLS_README.html

It warns against doing this.

You can ENFORCE the use of TLS, so that the Postfix SMTP server announces STARTTLS and accepts no mail without TLS encryption, by setting "smtpd_tls_security_level = encrypt". According to RFC 2487 this MUST NOT be applied in case of a publicly-referenced Postfix SMTP server. This option is off by default and should only seldom be used.

That RFC, though, is from January 1999

http://tools.ietf.org/html/rfc2487

and afaict has been superceded by

http://tools.ietf.org/html/rfc3207

from February 2002, which also says

"A publicly-referenced SMTP server MUST NOT require use of the
STARTTLS extension in order to deliver mail locally."

It's 14 years later, and a lot's changed in SSL usage.

Are there any later relevant RFCs that change this advice against forced TLS?

Regardless of RFC, in today's "SSL everywhere" atmosphere, is this still good, practical advice?

I've turned on smtpd_tls_loglevel=1, and will watch for awhile on my own servers.

What do you 'real world' Postfix admins see/do these days?

Jason
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

jasonsu


On Sat, Apr 9, 2016, at 09:33 AM, [hidden email] wrote:
> Per the DROWN mitigation, I stopped allowing sslv2 and sslv3

Did that as well.  Actually before even that point.

> so I made it a point to read the headers and look for encryption issues.

I admit I never even bothered to look for the effects of that^, voting instead for the BOFH-inspired "screw-em" approach.  In retrospect, I've never ended up missing a mail that made a tangible difference as a result.

> My conclusion is there is always "that one guy" that doesn't use encryption. In my case, literally one guy. Not being able to get his "regular" email to work, I got him to switch to gmail. ‎
>
> This is on my personal server. If you have customers, then each customer can have that "one guy", so it depends on how much time you want to sink into getting a third party to encrypt. 

Points made.  I'm not a provider, but do have clients.  I guess I'm thinking about how long to mollycoddle folks still in the dark ages, clients or not.

> I also made it a point to look for use of SPF and DKIM. Excluding the spammers that got through, nearly every user had both SPF and DKIM, but not all. One lacking SPF is a new business partner. The account without DKIM was a commercial vendor. My point here was I had considered setting up policies to reject email that didn't have both SPF and DKIM, but doing a survey realized there would be real situations where legitimate email would not get through.  One person I know uses pobox.com, and that fails SPF. 

I block on strict FAILs of any if SPF, DKIM or DMARC.  *missing* support for those is logged, but not - yet - acted on.

> I think policing everyone's email set up will lead to a lot of busy work. 

True.  One option is to stop policing, make sure MY postfix provides correct error-messages, and leave them to their own troubles.

Thanks for the comments.

'Someone' out there has some thorough statistics ... Interesting to know a bit more.

Jason
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

Viktor Dukhovni
In reply to this post by jasonsu
On Sat, Apr 09, 2016 at 08:46:54AM -0700, [hidden email] wrote:

> I'm setting up mandatory TLS policy for a couple of private client servers, using
>
> - smtpd_tls_security_level = may
> + smtpd_tls_security_level = encrypt
>
> I started wondering whether it wouldn't be a bad thing to require
> ALL email delivered to my server, from anywhere, to use TLS.

Your server, your rules, but be prepared to refuse a lot of legitimate
email.

    https://www.google.com/transparencyreport/saferemail/
    https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf
    https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

jasonsu


On Sat, Apr 9, 2016, at 02:02 PM, Viktor Dukhovni wrote:
> Your server, your rules, but be prepared to refuse a lot of legitimate
> email.

True, but that's neither my point, nor my goal.

And, THESE (sadly, neither of which I've seen)

>     https://www.google.com/transparencyreport/saferemail/
>     https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf
>     https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security

are great! resources.  stats!

For me, those mean "= may" remains for now.

Thanks

Jason
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

lists@lazygranch.com
In reply to this post by Viktor Dukhovni
Would  a guru comment on my "interpretation" of these documents?

1) It looks ‎to me that starttls really only protects the path to the first server. Classic case being sending email over the non-secure coffee shop wifi. 

2) Mail between Google/yahoo servers will enforce TLS, but other transit may not? My view of starttls email is this. At best, you only protect the endpoints. 

The snail mail analogy is you leave a message in an envelope for the mail carrier. That message makes it to the post office in the envelope. As the mail transits between post offices, some of those non-postal carriers may remove your envelope. The destination post office, should it find your message lacking an envelope, puts your message in another envelope, then delivers it.

3) I reviewed the DMARC. All my accounts have functional spf and dkim. If I set DMARC to quarantine, will  my email  at least be delivered? 

I've looked at dnssec, but it seems like I need a 2nd server to make it work. If not, can someone provide what they consider a good link on the topic?

My understanding is only pgp or s/mime has end to end encryption.

  Original Message  
From: Viktor Dukhovni
Sent: Saturday, April 9, 2016 2:03 PM
To: [hidden email]
Reply To: [hidden email]
Subject: Re: reality-check on 2016 practical advice re: requiring inbound TLS?

On Sat, Apr 09, 2016 at 08:46:54AM -0700, [hidden email] wrote:

> I'm setting up mandatory TLS policy for a couple of private client servers, using
>
> - smtpd_tls_security_level = may
> + smtpd_tls_security_level = encrypt
>
> I started wondering whether it wouldn't be a bad thing to require
> ALL email delivered to my server, from anywhere, to use TLS.

Your server, your rules, but be prepared to refuse a lot of legitimate
email.

https://www.google.com/transparencyreport/saferemail/
https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf
https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security

--
Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

Curtis Villamizar
In message <[hidden email]>
[hidden email] writes:
>
> Would a guru comment on my "interpretation" of these documents?

Not a guru but ...

> 1) It looks to me that starttls really only protects the path to the
>    first server. Classic case being sending email over the non-secure
>    coffee shop wifi.

If you are using TLS to port 587 then that is protecting the first
hop.  If both your MUA (email app) and the MSA (mail submission agent)
you are talking to insist on using TLS and have some means to mutually
authenticate (such as either a client cert or mutual_auth in postfix
on the MSA end), then this is subject to MITM.  Postfix does not
support validating the client cert (AFAIK - not a guru I said).

There is really no name to validate the client cert against, other
than the hostname provided in the EHLO.  For the MSA that could be
useful or the MSA could have a sender to name to validate mapping and
CAfile to use.  In principle, IMAP servers could do the same.  But I
don't think there is much demand for that.  It would mean getting
clients to put certs in the MUA.

The point of the article is that unless both ends insist on TLS then
MITM is possible.  There is a lot of discussion of STARTTLS
stripping.  There was not discussion of TLS downgrade attacks but
those are not as easy as STARTTLS stripping.

The focus of the paper was on the use of TLS between the MSA and the
MX of the destination domain (an MTA - mail transfer agent).  That is
usually the next hop.

> 2) Mail between Google/yahoo servers will enforce TLS, but other
>    transit may not? My view of starttls email is this. At best, you
>    only protect the endpoints.

Google, yahoo, and many others offer STARTTLS.  None require that you
use TLS or check a client cert.

> The snail mail analogy is you leave a message in an envelope for the
> mail carrier. That message makes it to the post office in the
> envelope. As the mail transits between post offices, some of those
> non-postal carriers may remove your envelope. The destination post
> office, should it find your message lacking an envelope, puts your
> message in another envelope, then delivers it.

Sort of.  More like if each post office always removed the envelope
and put your mail in a new one before sending to the next post office,
sometime a transparent envelope.

> 3) I reviewed the DMARC. All my accounts have functional spf and
>    dkim. If I set DMARC to quarantine, will my email at least be
>    delivered?

No.  I will be held and you (or some email address that is indicated
in the DMARC record) will be notified that mail for that domain is
held - typically in a daily summary for the domain.

> I've looked at dnssec, but it seems like I need a 2nd server to make
> it work. If not, can someone provide what they consider a good link on
> the topic?

You need to sign you domain RRs and then go to your domain registrar
and ask that a DS record be added for your domain.  In that order.

http://www.internetsociety.org/deploy360/dnssec/
http://www.internetsociety.org/deploy360/home/content-providers/dnssec/
http://dnssec-debugger.verisignlabs.com/
https://www.dnssec-tools.org/test/

The last one has a link to a tutorial.

Also regarding DANE:

http://www.internetsociety.org/deploy360/resources/dane/
http://dane.verisignlabs.com/
https://dane.sys4.de
https://dane.sys4.de/common_mistakes

> My understanding is only pgp or s/mime has end to end encryption.

Correct.  SMTP TLS is not end-to-end.

Of course to encrypt using pgp or s/mime both ends must support pgp or
s/mime which has been a problem.  People within various communities of
interest use pgp or s/mime (for example, the security community) but
use is very sparse.

Curtis


> > Original Message
> > From: Viktor Dukhovni
> > Sent: Saturday, April 9, 2016 2:03 PM
> > To: [hidden email]
> > Reply To: [hidden email]
> > Subject: Re: reality-check on 2016 practical advice re: requiring inbound TLS?
> >  
> > On Sat, Apr 09, 2016 at 08:46:54AM -0700, [hidden email] wrote:
> >  
> > > I'm setting up mandatory TLS policy for a couple of private client
> > > servers, using
> > >
> > > - smtpd_tls_security_level = may
> > > + smtpd_tls_security_level = encrypt
> > >
> > > I started wondering whether it wouldn't be a bad thing to require
> > > ALL email delivered to my server, from anywhere, to use TLS.
> >  
> > Your server, your rules, but be prepared to refuse a lot of legitimate
> > email.
> >  
> > https://www.google.com/transparencyreport/saferemail/
> > https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf
> > https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security
> >  
> > --
> > Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

Curtis Villamizar
In reply to this post by Viktor Dukhovni
In message <[hidden email]>
Viktor Dukhovni writes:

>
> On Sat, Apr 09, 2016 at 08:46:54AM -0700, [hidden email] wrote:
>  
> > I'm setting up mandatory TLS policy for a couple of private client
> >  servers, using
> >
> > - smtpd_tls_security_level = may
> > + smtpd_tls_security_level = encrypt
> >
> > I started wondering whether it wouldn't be a bad thing to require
> > ALL email delivered to my server, from anywhere, to use TLS.
>  
> Your server, your rules, but be prepared to refuse a lot of legitimate
> email.

A review of maillogs would tell you how much would get tossed.

I've been doing some work with automated parse of logs.  If I look at
that (including TLS mail rejected by postscreen vs in-the-clear mail
rejected by postscreen) I'll let you know.

>     https://www.google.com/transparencyreport/saferemail/
>     https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf
>     https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security
>  
> --
> Viktor.

Thanks for the links.  I emailed one of the authors asking why so
little was said about DNSSEC and nothing at all about DANE.

Curtis
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

lists@lazygranch.com
In reply to this post by Curtis Villamizar
I'm going to set the DMARC to  quarantine ‎and see what happens. I suppose I can always undo the DMARC to none.

Regarding dnssec, my registrar is Hover. Their faq is mighty convoluted since they provide a DNS server, though I use the one provided by Digital Ocean. Best to just get in a chat with hover and DO. 


  Original Message  
From: Curtis Villamizar
Sent: Saturday, April 9, 2016 6:32 PM
To: [hidden email]
Reply To: Curtis Villamizar
Cc: Viktor Dukhovni
Subject: Re: reality-check on 2016 practical advice re: requiring inbound TLS?

In message <[hidden email]>
[hidden email] writes:
>
> Would a guru comment on my "interpretation" of these documents?

Not a guru but ...

> 1) It looks to me that starttls really only protects the path to the
> first server. Classic case being sending email over the non-secure
> coffee shop wifi.

If you are using TLS to port 587 then that is protecting the first
hop. If both your MUA (email app) and the MSA (mail submission agent)
you are talking to insist on using TLS and have some means to mutually
authenticate (such as either a client cert or mutual_auth in postfix
on the MSA end), then this is subject to MITM. Postfix does not
support validating the client cert (AFAIK - not a guru I said).

There is really no name to validate the client cert against, other
than the hostname provided in the EHLO. For the MSA that could be
useful or the MSA could have a sender to name to validate mapping and
CAfile to use. In principle, IMAP servers could do the same. But I
don't think there is much demand for that. It would mean getting
clients to put certs in the MUA.

The point of the article is that unless both ends insist on TLS then
MITM is possible. There is a lot of discussion of STARTTLS
stripping. There was not discussion of TLS downgrade attacks but
those are not as easy as STARTTLS stripping.

The focus of the paper was on the use of TLS between the MSA and the
MX of the destination domain (an MTA - mail transfer agent). That is
usually the next hop.

> 2) Mail between Google/yahoo servers will enforce TLS, but other
> transit may not? My view of starttls email is this. At best, you
> only protect the endpoints.

Google, yahoo, and many others offer STARTTLS. None require that you
use TLS or check a client cert.

> The snail mail analogy is you leave a message in an envelope for the
> mail carrier. That message makes it to the post office in the
> envelope. As the mail transits between post offices, some of those
> non-postal carriers may remove your envelope. The destination post
> office, should it find your message lacking an envelope, puts your
> message in another envelope, then delivers it.

Sort of. More like if each post office always removed the envelope
and put your mail in a new one before sending to the next post office,
sometime a transparent envelope.

> 3) I reviewed the DMARC. All my accounts have functional spf and
> dkim. If I set DMARC to quarantine, will my email at least be
> delivered?

No. I will be held and you (or some email address that is indicated
in the DMARC record) will be notified that mail for that domain is
held - typically in a daily summary for the domain.

> I've looked at dnssec, but it seems like I need a 2nd server to make
> it work. If not, can someone provide what they consider a good link on
> the topic?

You need to sign you domain RRs and then go to your domain registrar
and ask that a DS record be added for your domain. In that order.

http://www.internetsociety.org/deploy360/dnssec/
http://www.internetsociety.org/deploy360/home/content-providers/dnssec/
http://dnssec-debugger.verisignlabs.com/
https://www.dnssec-tools.org/test/

The last one has a link to a tutorial.

Also regarding DANE:

http://www.internetsociety.org/deploy360/resources/dane/
http://dane.verisignlabs.com/
https://dane.sys4.de
https://dane.sys4.de/common_mistakes

> My understanding is only pgp or s/mime has end to end encryption.

Correct. SMTP TLS is not end-to-end.

Of course to encrypt using pgp or s/mime both ends must support pgp or
s/mime which has been a problem. People within various communities of
interest use pgp or s/mime (for example, the security community) but
use is very sparse.

Curtis


> > Original Message
> > From: Viktor Dukhovni
> > Sent: Saturday, April 9, 2016 2:03 PM
> > To: [hidden email]
> > Reply To: [hidden email]
> > Subject: Re: reality-check on 2016 practical advice re: requiring inbound TLS?
> >
> > On Sat, Apr 09, 2016 at 08:46:54AM -0700, [hidden email] wrote:
> >
> > > I'm setting up mandatory TLS policy for a couple of private client
> > > servers, using
> > >
> > > - smtpd_tls_security_level = may
> > > + smtpd_tls_security_level = encrypt
> > >
> > > I started wondering whether it wouldn't be a bad thing to require
> > > ALL email delivered to my server, from anywhere, to use TLS.
> >
> > Your server, your rules, but be prepared to refuse a lot of legitimate
> > email.
> >
> > https://www.google.com/transparencyreport/saferemail/
> > https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf
> > https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security
> >
> > --
> > Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

Viktor Dukhovni
In reply to this post by Curtis Villamizar
On Sat, Apr 09, 2016 at 09:36:09PM -0400, Curtis Villamizar wrote:

> >     https://www.google.com/transparencyreport/saferemail/
> >     https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf
> >     https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security
>
> Thanks for the links.  I emailed one of the authors asking why so
> little was said about DNSSEC and nothing at all about DANE.

    https://www.ietf.org/mail-archive/web/uta/current/msg01458.html
    https://www.youtube.com/watch?v=36WDbfKEIRI  (final minutes of Q&A)
    https://www.ietf.org/mail-archive/web/uta/current/msg01459.html

Short version from my perspective:

The authors seem to have STS/WebPKI tunnel-vision and appear to be
buying the party line that DNSSEC is too difficult to deploy, while
underestimating the deployment timescale for STS.

STS can only be deployed quickly between the handful of large
providers, and, on that scale, they have simpler means to exchange
the same data without new complex protocols.  This is of course
much faster than deploying DANE for a substantial fraction of the
Internet.

Deployment of STS for the Internet at large is unlikely to be much
faster than doing DANE at the same scale, and DANE is less kludgey
in this space.

That said, we may well support both at some point, when STS becomes
stable enough.  It need not be an either/or story.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

Viktor Dukhovni
In reply to this post by Curtis Villamizar
On Sat, Apr 09, 2016 at 09:31:48PM -0400, Curtis Villamizar wrote:

> > 1) It looks to me that starttls really only protects the path to the
> >    first server. Classic case being sending email over the non-secure
> >    coffee shop wifi.
>
> If you are using TLS to port 587 then that is protecting the first
> hop.  If both your MUA (email app) and the MSA (mail submission agent)
> you are talking to insist on using TLS and have some means to mutually
> authenticate (such as either a client cert or mutual_auth in postfix
> on the MSA end), then this is subject to MITM.  Postfix does not
> support validating the client cert (AFAIK - not a guru I said).

This is wrong.

> There is really no name to validate the client cert against, other
> than the hostname provided in the EHLO.

Submission clients are usually authenticated via SASL, and while
that does not provide "channel binding", it is good enough in
practice, if the client properly authenticates the server.

> The point of the article is that unless both ends insist on TLS then
> MITM is possible.  

The topic of the articles is TLS between email relays, not MUA to
submission or IMAP client to IMAP srever.

MITM is possible when SMTP relays (sending MTAs) don't (and generally
can't even if they wanted to) authenticate the nexthop MTA.

> The focus of the paper was on the use of TLS between the MSA and the
> MX of the destination domain (an MTA - mail transfer agent).  That is
> usually the next hop.

No, the topic was relay-to-relay SMTP, TLS is much more prevalent
with submission and IMAP and generally works adequately with WebPKI.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

lists@lazygranch.com
In reply to this post by Viktor Dukhovni
One interesting take away is that the corporate email servers were less likely to have SPF and DKIM in use. On the weekends, more email was sent from home users who tended to use Google, Hotmail, etc., which did use SPF and DKIM. 

I will admit my original intent on getting SPF and DKIM was to get a good score from SpamAssassin. You would think corporate emailers would want this as well. 

This went out on hacker news a few days ago :
https://news.ycombinator.com/item?id=11396089‎

  Original Message  
From: Viktor Dukhovni
Sent: Saturday, April 9, 2016 7:42 PM
To: [hidden email]
Reply To: [hidden email]
Subject: Re: reality-check on 2016 practical advice re: requiring inbound TLS?

On Sat, Apr 09, 2016 at 09:36:09PM -0400, Curtis Villamizar wrote:

> > https://www.google.com/transparencyreport/saferemail/
> > https://www.ietf.org/proceedings/95/slides/slides-95-irtfopen-1.pdf
> > https://www.elie.net/publication/neither-snow-nor-rain-nor-mitm-an-empirical-analysis-of-email-delivery-security
>
> Thanks for the links. I emailed one of the authors asking why so
> little was said about DNSSEC and nothing at all about DANE.

https://www.ietf.org/mail-archive/web/uta/current/msg01458.html
https://www.youtube.com/watch?v=36WDbfKEIRI (final minutes of Q&A)
https://www.ietf.org/mail-archive/web/uta/current/msg01459.html

Short version from my perspective:

The authors seem to have STS/WebPKI tunnel-vision and appear to be
buying the party line that DNSSEC is too difficult to deploy, while
underestimating the deployment timescale for STS.

STS can only be deployed quickly between the handful of large
providers, and, on that scale, they have simpler means to exchange
the same data without new complex protocols. This is of course
much faster than deploying DANE for a substantial fraction of the
Internet.

Deployment of STS for the Internet at large is unlikely to be much
faster than doing DANE at the same scale, and DANE is less kludgey
in this space.

That said, we may well support both at some point, when STS becomes
stable enough. It need not be an either/or story.

--
Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

Curtis Villamizar
In reply to this post by Viktor Dukhovni
In message <[hidden email]>
Viktor Dukhovni writes:
 

> On Sat, Apr 09, 2016 at 09:31:48PM -0400, Curtis Villamizar wrote:
>  
> > > 1) It looks to me that starttls really only protects the path to the
> > >    first server. Classic case being sending email over the non-secure
> > >    coffee shop wifi.
> >
> > If you are using TLS to port 587 then that is protecting the first
> > hop.  If both your MUA (email app) and the MSA (mail submission agent)
> > you are talking to insist on using TLS and have some means to mutually
> > authenticate (such as either a client cert or mutual_auth in postfix
> > on the MSA end), then this is subject to MITM.  Postfix does not
> > support validating the client cert (AFAIK - not a guru I said).
>  
> This is wrong.

Can you say what is wrong.  Let me paraphrase and expand a bit.

mutual_auth implies you are using SASL.

With Opportunistic TLS without SASL in postfix you have no
authentication.

With TLS but with SASL plaintext you provide a MITM a means to read
your password.

The simplest MITM is STARTTLS stripping.  If the client end doesn't
insist on TLS, then STARTTLS stripping is possible.  The client TCP
connection can be terminated at the MITM as plain text and a TLS to
the MSA can be started.  In both connections the IP address can be
spoofed if the MITM is in the routing middle (or acting as a L2
bridge).

If both ends insist on TLS but are willing to settle for SSL, then a
MITM is still possible with a TLS downgrade (but harder to do).

If both ends insist on TLS and not SSL but there is no client cert and
no way to tell what the client should be signing for or no CAfile to
check against then a MITM is possible if a rouge CA is used (which is
likely going to be a nation surveilance situation).

Postfix does not support validating the client cert.

Which of these are wrong?  OK to pick more than one.  :-)

Seriously, I did say I'm not an expert.

> > There is really no name to validate the client cert against, other
> > than the hostname provided in the EHLO.
>  
> Submission clients are usually authenticated via SASL, and while
> that does not provide "channel binding", it is good enough in
> practice, if the client properly authenticates the server.

mutual_auth implies you are using SASL and with or without TLS it
helps with MITM, but safe with TLS.

mutual_auth such as SCRAM (or GSSAPI) are reasonably good and MITM
resistant.

> > The point of the article is that unless both ends insist on TLS then
> > MITM is possible.  
>  
> The topic of the articles is TLS between email relays, not MUA to
> submission or IMAP client to IMAP srever.
>  
> MITM is possible when SMTP relays (sending MTAs) don't (and generally
> can't even if they wanted to) authenticate the nexthop MTA.

This statement was independent on MUA->MSA or MSA->MX which is a form
of MTA->MTA.

> > The focus of the paper was on the use of TLS between the MSA and the
> > MX of the destination domain (an MTA - mail transfer agent).  That is
> > usually the next hop.
>  
> No, the topic was relay-to-relay SMTP, TLS is much more prevalent
> with submission and IMAP and generally works adequately with WebPKI.

Sorry.  We are saying the same thing here but I was keeping with
MUA->MSA or MSA->MX since explaining to someone that possibly didn't
know any of these terms.  And MSA->MX is a form of MTA->MTA.

To be pedantic, the focus of the paper is on MTA->MTA where the two
MTA are in different domains.

> --
> Viktor.

I defer to you as an expert on this but I would like to know what is
wrong in the "this is wrong" comment.

Curtis
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

Viktor Dukhovni
In reply to this post by lists@lazygranch.com
On Sat, Apr 09, 2016 at 08:32:10PM -0700, [hidden email] wrote:

> One interesting take away is that the corporate email servers were less
> likely to have SPF and DKIM in use. On the weekends, more email was sent
> from home users who tended to use Google, Hotmail, etc., which did use
> SPF and DKIM. 

I suspect that's not the whole story, if you look at the weekend
peaks and troughs before Gmail started displaying a transport security
indication for delivered mail, you'll see that the gap between the
two was much higher than it is now.  You'll also notice that the
mainstream senders of bulk email marketing who are always in the
top 20 senders on the transparency page recently went from 0% TLS
to 100% TLS.

So my take on the numbers is that the commercial mailers make up
a larger proportion of email traffic into Gmail on weekdays than
on weekends.  If it was just or predominantly the difference between
corporate and home senders, the size of the weekday dip would not
have changed, just the baseline would have moved up.  The corporate
world does not react to changes of Gmail's user interface within
days of those changes.  Only the professional email marketers are
that agile.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

Bill Cole-3
In reply to this post by jasonsu
On 9 Apr 2016, at 12:45, [hidden email] wrote:

> I block on strict FAILs of any if SPF, DKIM or DMARC.  *missing*
> support for those is logged, but not - yet - acted on.

This is dangerous, as is raising the bar too high on ciphersuites.

Case in point: Ditech is one of the largest mortgage servicing companies
in the US, servicing millions of loans ultimately held by the federal
government. They send email responses to customer service inquiries out
via Microsoft's Office365 service, which signs it for the
"gtservicing.onmicrosoft.com" domain, but has it routed through Cisco
(formerly Ironport's) "iphmx.com" infrastructure for no visible reason,
where the From header is apparently re-written to
<[hidden email]>, breaking the DKIM signature. While the
iphmx.com machines accept mail from Microsoft using the suboptimal
AES256-SHA ciphersuite, they inexplicably use the affirmatively weak
TLSv1/RC4-SHA to pass it along. Because of this arcane routing, the
envelope sender ([hidden email]) has a domain with an SPF
record that is invalid due to its excessive complexity. Topping this
off, their messages consistently contain nothing but a bunch of
disclaimer boilerplate plus a link to the REAL message (which thankfully
is also usually low-content boilerplate) in a .doc file on the
sharefile.com service, with no authentication required to access the
link.

This is how security-competent a significant US financial services
company is regarding email: broken DKIM signatures, invalid SPF records,
and confidential information regarding mortgage accounts sitting at URLs
accessible by anyone who can intercept a piece of email which AT BEST is
transported using encryption which may be crackable in reasonable time
by entities much weaker than the NSA.

BUT: People *REALLY* want their customer service email from Ditech. If
you block invalid SPF, it fails. If you block invalid DKIM signatures,
it fails. If you require strong encryption, it fails. It is possible (I
have not tested...) that if you require strong encryption or none ("may"
with a restrictive cipherlist) they may deliver potentially critically
private information in the clear.

Welcome to 2016: Sturgeon's Law remains in effect.
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

jasonsu
On Sun, Apr 10, 2016, at 03:13 PM, Bill Cole wrote:
> On 9 Apr 2016, at 12:45, [hidden email] wrote:
>
> > I block on strict FAILs of any if SPF, DKIM or DMARC.  *missing*
> > support for those is logged, but not - yet - acted on.
>

> as is raising the bar too high on ciphersuites.

That I'm sold on.

> This is dangerous,

This, not so much.

> Case in point: Ditech ...

Great example & reminder.

But,

(1) I'm not an ESP
(2) If a company publishes a policy, then fails to follow it, not my problem.  It's theirs.

Yep I know that that's gonna cost me some 'Ditech-esque' mail.

> Welcome to 2016: Sturgeon's Law remains in effect.

Unfortunately, Sturgeon -- as was Orwell -- was an optimist :-/

Jason
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

Curtis Villamizar
In reply to this post by Bill Cole-3
In message <[hidden email]>
"Bill Cole" writes:

>
> On 9 Apr 2016, at 12:45, [hidden email] wrote:
>  
> > I block on strict FAILs of any if SPF, DKIM or DMARC.  *missing*
> > support for those is logged, but not - yet - acted on.
>  
> This is dangerous, as is raising the bar too high on ciphersuites.
>  
> Case in point: Ditech is one of the largest mortgage servicing companies
> in the US, servicing millions of loans ultimately held by the federal
> government. They send email responses to customer service inquiries out
> via Microsoft's Office365 service, which signs it for the
> "gtservicing.onmicrosoft.com" domain, but has it routed through Cisco
> (formerly Ironport's) "iphmx.com" infrastructure for no visible reason,
> where the From header is apparently re-written to
> <[hidden email]>, breaking the DKIM signature. While the
> iphmx.com machines accept mail from Microsoft using the suboptimal
> AES256-SHA ciphersuite, they inexplicably use the affirmatively weak
> TLSv1/RC4-SHA to pass it along. Because of this arcane routing, the
> envelope sender ([hidden email]) has a domain with an SPF
> record that is invalid due to its excessive complexity. Topping this
> off, their messages consistently contain nothing but a bunch of
> disclaimer boilerplate plus a link to the REAL message (which thankfully
> is also usually low-content boilerplate) in a .doc file on the
> sharefile.com service, with no authentication required to access the
> link.
>  
> This is how security-competent a significant US financial services
> company is regarding email: broken DKIM signatures, invalid SPF records,
> and confidential information regarding mortgage accounts sitting at URLs
> accessible by anyone who can intercept a piece of email which AT BEST is
> transported using encryption which may be crackable in reasonable time
> by entities much weaker than the NSA.
>  
> BUT: People *REALLY* want their customer service email from Ditech. If
> you block invalid SPF, it fails. If you block invalid DKIM signatures,
> it fails. If you require strong encryption, it fails. It is possible (I
> have not tested...) that if you require strong encryption or none ("may"
> with a restrictive cipherlist) they may deliver potentially critically
> private information in the clear.
>  
> Welcome to 2016: Sturgeon's Law remains in effect.


Great anecdote of a really bad email setup but ...

For a lot of us missing out on Ditech, a specialist in preditory
lending, is not a compelling reason not to enable SPF, DKIM and DMARC.

For my domains (all automated DNS zone file generation) I publish SPF
and DKIM (and any relevant DNSSEC crud and TLSA) and was planning to
update the homegrown tool to add DMARC.  By publishing those records,
you just avoid having someone forge mail as you (including to you, but
there are plenty of simpler ways to protect against that).  I was also
planning to reject based on opendmarc at some point in the
not-so-distant future.

Curtis
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

lists@lazygranch.com
In reply to this post by jasonsu
Then again, the customer service department for an item I ordered has no DKIM. The company is using netsuite.com as a portal.  I suppose I can try to contact their IT...

I found another legit emailer with SPF but no DKIM. A corporate user that is using a barracuda service of some sort. 

I've yet to find email from an actual person that doesn't have DKIM or SPF. It is the "and" that doesn't work.

One of the email verification services put me in the top 3% of servers based on security. At the time, I though that was nuts. But looking typical email headers, that might be true. 




  Original Message  
From: [hidden email]
Sent: Sunday, April 10, 2016 4:08 PM
To: [hidden email]
Subject: Re: reality-check on 2016 practical advice re: requiring inbound TLS?

On Sun, Apr 10, 2016, at 03:13 PM, Bill Cole wrote:
> On 9 Apr 2016, at 12:45, [hidden email] wrote:
>
> > I block on strict FAILs of any if SPF, DKIM or DMARC. *missing*
> > support for those is logged, but not - yet - acted on.
>

> as is raising the bar too high on ciphersuites.

That I'm sold on.

> This is dangerous,

This, not so much.

> Case in point: Ditech ...

Great example & reminder.

But,

(1) I'm not an ESP
(2) If a company publishes a policy, then fails to follow it, not my problem. It's theirs.

Yep I know that that's gonna cost me some 'Ditech-esque' mail.

> Welcome to 2016: Sturgeon's Law remains in effect.

Unfortunately, Sturgeon -- as was Orwell -- was an optimist :-/

Jason
Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

Viktor Dukhovni

> On Apr 10, 2016, at 8:49 PM, [hidden email] wrote:
>
> I've yet to find email from an actual person that doesn't have DKIM or SPF.

I've never emailed you directly.  This will be the first time.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: reality-check on 2016 practical advice re: requiring inbound TLS?

Bill Cole-3
In reply to this post by Curtis Villamizar
On 10 Apr 2016, at 20:00, Curtis Villamizar wrote:

> Great anecdote of a really bad email setup but ...
>
> For a lot of us missing out on Ditech, a specialist in preditory
> lending, is not a compelling reason not to enable SPF, DKIM and DMARC.

The power of a brand shows itself...

Whether or not one approves of the company that now owns and
inexplicably chose to revive the Ditech brand name recently is
irrelevant, as are the predatory practices of GMAC when they existed and
owned that brand. People with conventional "prime" mortgages don't
really have any say in who services their loan from one year to the
next: the servicing rights become a highly liquid market commodity once
Fannie or Freddie holds the actual loan.

My point was that there are companies that people cannot readily choose
to not do business with who send mail in ways which indicate that they
have tried but very much failed to adhere to modern security standards.
On a system where you know enough about all your users to know that they
don't want to get critical email from clueless sources, you can make
restrictive choices with no trouble. If you don't actually know that,
choosing to require senders to use rigorous security correctly will
often lead to unpleasant surprises.
12