Subject: [ietf-smtp] How to encrypt SMTP?

From: Дилян Палаузов <[email-masked]>
Date: Wed, 16 Oct 2019 17:43:07 +0000

Hello,

MTA-STS and DANE for SMTP answer the question when must be either encrypted, or the delivery postponed.

How shall it be encrypted?

Some sites (tools) present information, based on the provided protocols and ciphers, which browsers will work with a
HTTPS-webserver, and which not.  And one can decide, that accepting connections from IE 8 is not a priority.

But for SMTP there is nothing similar.  What matters is, if a weak cipher is disabled on a mailhost, which sites will
not be able to use STARTTLS with that host.  E.g. disabling TLS 1.0 (and SSL 3) will not allow anymore to encrypt
traffic with @gnu.org .

Some questions:

What happens to MTAs, that are so smart to understand MTA-STS or DANE, but offer only weak ciphers?

Does somebody offer both EC and RSA certificates on its smtp:25 server and had this ever caused problems?

Does somebody offer both EC and RSA certificates with DANE on its smtp:25 server and had this ever caused problems?

How much bits shall DH params have to support acceptable amount of mailhosts?  Do too big DH params break some clients?

What elliptic curves shall be offered, so that the communication works with acceptable amount of hosts?

>From which moment there shall be penalties, in terms of sticking to unencrypted traffic, for mailhosts offering only
weak encryption?  Will this happen chaotically, or any advices can be drafted?

Regards
  Дилян

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Wed, 16 Oct 2019 14:00:41 -0400

On Wed, 16 Oct 2019 17:43:07 -0000, Дилян Палаузов said:
> But for SMTP there is nothing similar.  What matters is, if a weak cipher is
> disabled on a mailhost, which sites will not be able to use STARTTLS with that
> host.  E.g. disabling TLS 1.0 (and SSL 3) will not allow anymore to encrypt
> traffic with @gnu.org .

The same thing that happens with anybody else who runs deprecated services - at
some point they've gotten enough reports of problems that they get around to
upgrading.

Seriously - if gnu.org *still* doesn't support TLS 1.1 (RFC4346 came out in
April 2006), they're probably running an SSL/TLS software stack that has about
4 zillion since-patched security holes in it.  And it *also* means that their
MTA software dates back to a release that doesn't insist on 1.1 or later -
which means there's probably a whole raft of since-patched security holes in
that as well.

---

From: "John Levine" <[email-masked]>
Date: 16 Oct 2019 15:53:14 -0400

In article <167179.1571248841@turing-police> you write:
>4 zillion since-patched security holes in it.

They're running Exim 4.71 which was released in 2009.  The current
version is 4.92.3.  Their mail software is a decade out of date.

This is not a hard problem to solve.

---

From: Hector Santos <[email-masked]>
Date: Wed, 16 Oct 2019 22:45:35 -0400

> This is not a hard problem to solve.

Its a difficult compatibility problem to solve. In this case, are you 
(speaking in general) going instruct or program your Port 25 SMTP 
client to accept only a higher degree of encryption? Or vice-versa? 
The OP is correct. With SMTP, the higher SSL bar has not been imposed 
even with  uptopar software. With modern browsers, you can feel the 
pains.  Just consider, how will HSTS concepts work in SMTP?

-- 
HLS

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 Oct 2019 23:03:29 -0400

> On Oct 16, 2019, at 1:43 PM, Дилян Палаузов <[email-masked]> wrote:
> 
> Some questions:
> 

MTA-STS specifies at least TLS 1.2:

	https://tools.ietf.org/html/rfc8461#section-7.2

So operators who enable MTA-STS, but only TLS 1.0 are negligent, and will encounter
problems.

DANE (~3 years earlier) specifies at least TLS 1.0 and SHOULD TLS 1.2:

	https://tools.ietf.org/html/rfc7671#section-3

The Postfix TLS implementation does not allow enable ciphers
when TLS is mandatory, and these are rapidly disappearing
entirely from TLS stacks.

> Does somebody offer both EC and RSA certificates on its smtp:25 server and had this ever caused problems?

This generally just works.

> Does somebody offer both EC and RSA certificates with DANE on its smtp:25 server and had this ever caused problems?

Yes, there are such sites.  This just works with MTA-STS and DANE-TA(2)
trust-anchor TLSA RRs, as only the name in the certificate matters, the
algorithm is not so important.  With DANE-EE(3), the TLSA RR becomes
public-key-dependent, and multiple TLSA RRs are needed when fielding
certs for multiple algorithms.  See 

    https://www.mail-archive.com/[email-masked]/msg00284.html
    https://www.mail-archive.com/[email-masked]/msg00285.html

But multi-cert MTAs are uncommon, and this is not actually difficult
to get right, single-cert rollover blunders account for almost all
problem cases.

> How much bits shall DH params have to support acceptable amount of mailhosts?

I don't know of any MTAs that will refuse 1024-bit DH, but better to
use 2048 and better still ECDHE with P-256.

>  Do too big DH params break some clients?

Yes, Java.

> What elliptic curves shall be offered, so that the communication works with acceptable amount of hosts?

The "market consensus" is NIST P256, everything else is rare,
but you need to enable negotiation, and also support P384,
just in case.  There is also non-trivial use of X25519 these
days, but systems that use it, can also use P256 as needed.

-- 
	Viktor.

---

From: Дилян Палаузов <[email-masked]>
Date: Sat, 26 Oct 2019 13:33:32 +0000

Hello Viktor,

thanks for your answer.

Why is it common for https-providers to offer both RSA and EC certificates, but it is not common for IMAP or SMTP
providers to offer EC certificates?  I mean, if EC offers less calculations without sacrificing security, why nobody
makes use of this?

> entirely from TLS stacks.

I do not get the last paragraph.

Greetings
  Дилян

---

From: Jeremy Harris <[email-masked]>
Date: Sat, 26 Oct 2019 16:57:58 +0100

> I do not get the last paragraph.

Possibly s/allow enable ciphers/allow anonymous ciphers/ ?
-- 
Cheers,
  Jeremy

---

From: "John Levine" <[email-masked]>
Date: 26 Oct 2019 14:59:58 -0400

>providers to offer EC certificates?  I mean, if EC offers less calculations without sacrificing security, why nobody

Probably because the TLS parts of MTAs get less attention than the TLS
part of web browsers and servers.  Everyone uses the same handful of
underlying crypto libraries (opensssl, gnutle, a few others) so in the
MTA it's mostly just tweaking parameters to the library calls.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 26 Oct 2019 23:04:59 +0200

> On Oct 26, 2019, at 3:33 PM, Дилян Палаузов <[email-masked]> wrote:
> 

MTAs are difficult enough to operate without the extra complexity of
managing certs for multiple algorithms.  For mostly opportunistic TLS,
there's not much incentive to jump through complex TLS hoops.

> but offer only weak ciphers?

I meant to say that Postfix disables weak ciphers when TLS is mandatory,
(e.g. when DANE or MTA-STS is used).  So anyone configuring DANE or MTA-STS
needs to implement the MTI TLS 1.2 ciphers and generally most of the reasonably
strong alternatives.

-- 
	Viktor.

---

From: Keith Moore <[email-masked]>
Date: Sat, 26 Oct 2019 18:28:58 -0400

> On Oct 26, 2019, at 5:05 PM, Viktor Dukhovni <[email-masked]> wrote:
> 
> For mostly opportunistic TLS,

Yes but IMO we should be moving toward a world in which TLS is mandatory for SMTP relay.    Clear guidance to implementors and operators on what TLS versions, cert algorithms, and ciphersuites a client and server should support, might help us get there.

(perhaps as a stepping stone, cleartext mail relay could be pessimized by having servers randomly return 4xx in response to MAIL sent without TLS, obsolete TLS, or weak ciphersuites, with the probability of such responses increasing over time.)

Keith

---

From: "John Levine" <[email-masked]>
Date: 26 Oct 2019 20:25:53 -0400

In article <[email-masked]> you write:
>Yes but IMO we should be moving toward a world in which TLS is mandatory for SMTP relay.    Clear guidance to implementors
>and operators on what TLS versions, cert algorithms, and ciphersuites a client and server should support, might help us get there.

I don't think that's the problem.  I don't see any SMTP TLS failures other than from spambots.

>(perhaps as a stepping stone, cleartext mail relay could be pessimized ...

We already have mta-sts, which says that cleartext is forbidden for
the domains it's published for.  Why reinvent another wheel?

R's,
John

---

From: Keith Moore <[email-masked]>
Date: Sat, 26 Oct 2019 20:36:23 -0400

> I don't think that's the problem.  I don't see any SMTP TLS failures other than from spambots.
That sounds good, but I'd like to understand more precisely what you're 
observing.
> the domains it's published for.  Why reinvent another wheel?

Maybe it's not necessary, but I don't know how widely mta-sts is being 
required.   What are the barriers to server operators turning on MTA-STS 
everywhere?

Keith

---

From: "John R Levine" <[email-masked]>
Date: 26 Oct 2019 20:47:42 -0400

> required.   What are the barriers to server operators turning on MTA-STS 

It's pretty easy to deploy for your inbound servers, publish some DNS 
records and set up some trivial web pages. (See 
https://mta-sts.taugh.com/.well-known/mta-sts.txt)

For outbound mail it's somewhat harder, you have to look at what's on the 
web page and decide whether it matches what the MTA is seeing.

I expect the main barrier is that large scale operators see failures on 
legit traffic that would be invisible to us little guys, but enough of 
them that they're not ready to accept that level of breakage.  A useful 
thing that mta-sts borrows from DMARC is reports about what would have 
broken if it were enforced, so they can try and figure it out and fix it.

I believe it's the same reason that Google doesn't sign their domains with 
DNSSEC.  They certainly could if they wanted to.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Keith Moore <[email-masked]>
Date: Sat, 26 Oct 2019 21:02:55 -0400

On 10/26/19 8:47 PM, John R Levine wrote:

>> Maybe it's not necessary, but I don't know how widely mta-sts is 
>> being required.   What are the barriers to server operators turning 
>> on MTA-STS everywhere? 

> I expect the main barrier is that large scale operators see failures 
> on legit traffic that would be invisible to us little guys, but enough 
> of them that they're not ready to accept that level of breakage.

Yeah, that's what I was getting at.   I've often suspected that there 
were more distinct implementations of SMTP than nearly any other 
protocol, even more than HTTP.    That's a lot of implementations that 
need to be upgraded (at least, all of those used for mail relaying and 
not merely submission), and I'd expect the long tail to take a long time.

If I were an email service operator I'd be reluctant to reject 
legitimate mail.  But of course spam filters are already doing this to 
an astonishingly high degree and that has become accepted practice 
(sigh).   So maybe a general requirement to use TLS for mail relaying 
between administrative domains wouldn't look like a huge change.   Maybe 
it would even be justified as a spam deterrent.

My only thought regarding 4xx was that sometimes a soft incentive works 
better than a hard one.   If relaying mail by cleartext still "worked", 
only more slowly because clients had to retry X% of the time, that seems 
to me to provide a more workable feedback path to the operators not 
using TLS, than a sudden hard refusal to accept cleartext SMTP.

> I believe it's the same reason that Google doesn't sign their domains 
> with DNSSEC.  They certainly could if they wanted to.

Nor sure I get the analogy.   AFAIK if Google signed their domains, the 
only things that would break would be broken DNS clients/resolvers doing 
verification, which would hopefully be few in number.

Keith

---

From: "John Levine" <[email-masked]>
Date: 26 Oct 2019 21:10:48 -0400

>That sounds good, but I'd like to understand more precisely what you're 

I'm looking at my incoming and outgoing mail logs.  FWIW, the vast
majority of the outgoing mail goes over TLS.  Partly that's because a
whole lot of mail goes to a fairly small set of providers (Google,
Microsoft, Mimecast, etc.) but I see lots of TLS to small mail
servers, too.  The non-TLS mail is what you'd expect, small
unsophisiticated mail operators, mostly not in North America.

R's,
John

---

From: "Valdis Klētnieks" <[email-masked]>
Date: Sat, 26 Oct 2019 21:13:16 -0400

> it would even be justified as a spam deterrent.

I wonder what percent of spammers would have any problems and if any spam
would actually be blocked.  They were on the bleeding edge of adopting SPF and
similar, after all.

> verification, which would hopefully be few in number.

On my more cynical days, I contemplate whether breaking such clients is the
fastest way to get them fixed.....

---

From: "John Levine" <[email-masked]>
Date: 26 Oct 2019 21:17:42 -0400

>verification, which would hopefully be few in number.

I gather that the number of ways that middleboxes can screw up the DNS
is far greater than we can imagine.  And getting people to fix it is not
easy since "the box works fine" and DNS works fine, too.

---

From: Keith Moore <[email-masked]>
Date: Sat, 26 Oct 2019 21:22:51 -0400

On 10/26/19 9:13 PM, Valdis Klētnieks wrote:
>> between administrative domains wouldn't look like a huge change.�� Maybe

Note I did say maybe such a practice would be /justified/ as a spam 
deterrent.   Many things that have been justified in that way, don't 
actually serve that purpose in practice.   From one perspective, the 
greatest effect of spam filtering has been to make Internet email 
unreliable for general use.

But overall I'm a lot more interested in having email universally 
encrypted, than I am in having yet another half-baked spam deterrent.   
But if that's what it takes to get people to do it, it might be a good 
thing.

>> Nor sure I get the analogy.�� AFAIK if Google signed their domains, the

It's not like we've never seen cases where breakage helped to fix things.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 26 Oct 2019 21:24:34 -0400

> easy since "the box works fine" and DNS works fine, too.

Ah yes, interesting point.   And users do have strange ideas as to what 
"works fine".

What's the half-life of a broken middlebox?   I'm guessing about 10 years.

Keith

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 27 Oct 2019 09:01:36 +0100

> On Oct 27, 2019, at 2:47 AM, John R Levine <[email-masked]> wrote:
> 
> I believe it's the same reason that Google doesn't sign their domains with DNSSEC.

Google have signed *some* of their domains with DNSSEC, in particular:

	mx[1-4].smtp.goog

are signed, and are equally valid MX hosts for Gmail and other domains,
you'll even find these names in the presented certificate.  What they've
not as yet been able to do is sign google.com, I'm inclined to speculate
that this is related to complications getting the DNS load-balancers to do
DNSSEC.

> They certainly could if they wanted to.

Yes, see above, but DNSSEC for "google.com" is likely to take more time.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 27 Oct 2019 09:09:38 +0100

> On Oct 27, 2019, at 2:24 AM, Keith Moore <[email-masked]> wrote:
> 
> Ah yes, interesting point.   And users do have strange ideas as to what "works fine".
> 

The middlebox breakage affects mobile users in hotels, airports, home
networks, ...  It has little to no effect on MTAs in data-centres.
MTA-to-MTA DNSSEC does not face any meaningful middle-box barriers.

There are (today) ~1.35 million DNSSEC-signed domains with DNSSEC-signed MX
hosts that have DANE TLSA records.

The only issue is that some hosting providers with very old broken DNSSEC
authoritative servers don't return valid denial of existence for MX-host
TLSA records.  This affects ~800 out of 10 million signed domains.  None
are significant sources or sinks of email.

Bottom line, sign-away, you'll not have any issues, unless your domain
is hosted by a small number of small (mostly Dutch) providers.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 27 Oct 2019 11:00:12 -0400

In article <[email-masked]> you write:
>MTA-to-MTA DNSSEC does not face any meaningful middle-box barriers. ...

>is hosted by a small number of small (mostly Dutch) providers.

I agree that the DNSSEC problems have close to nothing to do with mail issues.
But it's hard to sign the MX records for a domain without also signing the A
and AAAA records.

R's,
John

---

From: Дилян Палаузов <[email-masked]>
Date: Sun, 27 Oct 2019 19:58:17 +0000

Hello Keith,

> (perhaps as a stepping stone, cleartext mail relay could be pessimized by having servers randomly return 4xx in response to MAIL sent without TLS, obsolete TLS, or weak ciphersuites, with the proba…

There is no big difference in the penalty between randomly returning 4xx on MAIL and randomly returning 4xx on RCPT and
the latter is effectively mail segmentation.

If random 4xx on MAIL as penalty for not offering reasonable TLS will help make things better, will random mail
segmentation as penalty for senders not supporting PRDR, convince anybody to implement PRDR?

Greetings
  Дилян

---

From: Keith Moore <[email-masked]>
Date: Sun, 27 Oct 2019 16:39:30 -0400

> segmentation as penalty for senders not supporting PRDR, convince anybody to implement PRDR?

I don't think they're going to be well-correlated, because the benefits 
from encrypting mail transport and the benefits from optimizing mail 
error reporting are different.   They benefit different parties, and the 
perceived importance of encryption is different than the perceived 
importance of optimizing mail error reporting.

I support the idea behind PRDR and am not aware of any drawbacks to 
implementing it.   In general my observation is that the earlier mail 
transmission errors are caught and reported, the more reliable the 
reporting is; and the overall reliability of email improves by improving 
error reporting.

Keith

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 28 Oct 2019 10:42:07 -0400

> On Oct 27, 2019, at 11:00 AM, John Levine <[email-masked]> wrote:
> 

Yes, signatures are zone-wide, but while mobile clients behind broken
middleboxes may not be able to take advantage of DNSSEC signatures,
they generally continue to function, with DNS security disabled.  Were
that not the case, ~10 million signed domains would have DNSSEC-related
problems serving web pages (which is not the case).  Top 20 slightly
dated website ranks of DNSSEC signed domains:

    50 mozilla.org
    75 nih.gov
    84 paypal.com
    91 europa.eu
   132 force.com
   181 stanford.edu
   194 quizlet.com
   210 cloudflare.com
   221 nasa.gov
   228 debian.org
   235 canva.com
   240 time.com
   246 cdc.gov
   251 taboola.com
   262 foxnews.com
   268 washingtonexaminer.com
   280 mediafire.com
   281 statcounter.com
   283 thestartmagazine.com
   304 berkeley.edu

-- 
	Viktor.