Subject: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Sat, 5 Jan 2019 21:20:36 +0530

Hello UTA WG,

I have a proposal for SMTPS (Implicit TLS), port 25 secure alternative on a
new dedicated port 26.

Both MTA-STS and MTA-DANE tries to fix the STARTTLS downgrade issue.
However the implementation is not simple. The former requires a HTTPS
server and the latter requires DNSSEC.

I'm proposing a very simple solution. It's actually dead simple. So i'm not
really sure whether it was proposed before and got rejected for some
reasons or you guys really missed that one.

I'm hoping it was the latter. But If it was already proposed and rejected,
then forgive my ignorance.

The content is prepared for a blog post. You guys don't have to go through
everything. Read abstract and then skip to the proposal section.

https://gist.github.com/mistergiri/a4c9a5f1c26fd7003ebc0652af95d314

Let me know if it is worth the effort. If it is, then I'm happy to create a
draft for IETF proposal.

Thanks
-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.

---

From: Jeremy Harris <[email-masked]>
Date: Sat, 5 Jan 2019 17:11:32 +0000

On 05/01/2019 15:50, Viruthagiri Thirumavalavan wrote:
> I'm proposing a very simple solution. It's actually dead simple.

You seem to be part-duplicating the intent of a DNS SRV record.

Wouldn't the definition of a service name "smtps" with no hardcoded
port number (per RFC 6335), and the use of SRV per RFC 2782, do the
job and be preferred to an ad-hoc method?
-- 
Cheers,
  Jeremy

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 5 Jan 2019 15:11:00 -0500

> On Jan 5, 2019, at 10:50 AM, Viruthagiri Thirumavalavan <[email-masked]> wrote:
> 
> I have a proposal for SMTPS (Implicit TLS), port 25 secure alternative on a new dedicated port 26.
> 
> Both MTA-STS and MTA-DANE tries to fix the STARTTLS downgrade issue. However the implementation is not simple. The former requires a HTTPS server and the latter requires DNSSEC. 
> 
> I'm proposing a very simple solution. It's actually dead simple. So i'm not really sure whether it was proposed before and got rejected for some reasons or you guys really missed that one.

This adds complexity, without solving any problems.  I'm afraid
this proposal has no merit.

*  The attacker can just as easily block connections to port 26,
   as filter out STARTTLS.

*  This in no way addresses the authentication issues.

There are more problems, but those two are enough to make further
discussion of the proposal pointless.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 5 Jan 2019 16:22:22 -0500

>reasons or you guys really missed that one.

This sort of thing, encoding stuff in domain names, is a non-starter.
For one thing, it doesn't work with IDNs.  For another, mail servers
don't know what their names are and is quite common to point hundreds
or thousands of MX records at the same server if it handles a lot of
client mail domains.  What happens when (not if) they aren't
consistent?

Also, more practically, anything like this requires a change to the
way that mail clients look for mail servers, and if you're going to
change, change to SRV which is already well defined and in use in
other applications such as SIP.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Sun, 6 Jan 2019 05:48:46 +0530

Thanks guys. Appreciate the responses.

> job and be preferred to an ad-hoc method?

My intention was avoiding those extra DNS lookups. As a developer, I would
rather prefer to have a simple "if string starts with" check, rather than
performing a DNS lookup like "_smtps._tcp.example.com". The majority not
gonna have that record. So we are wasting the lookups there.

> *  This in no way addresses the authentication issues.

I already addressed both issues in the document. Refer "Deprecation" and
"Security Considerations" section. My proposal is all about deprecating
"Plain Text" in port 25.

> For one thing, it doesn't work with IDNs.

You got me here. I don't have any experience with IDN. So I can't argue
with this one. I hope we can atleast use numbers as prefix if not english
characters. If no prefix possible in IDN, then yes it's a non-starter

For another, mail servers
> client mail domains.  What happens when (not if) they aren't

I'm not following you. I hope you are talking about third party mail
hosting services like Google Apps. If yes, then I addressed that in the
"Migration => Third Party Hosted" section.

> way that mail clients look for mail servers

This is what I mentioned in my document.

*The "26pref" says "We prefer if you connect to our SMTPS in port 26. But
we also accept mails in port 25".*

*So now SMTP clients can check for whether MX server starts with the string
"26pref". If it starts with that string, then the clients gonna connect to
port 26 (smtps). A normal client that doesn't know what "26pref" stands for
gonna connect to port 25 as usual.*

Thanks

On Sun, Jan 6, 2019 at 2:52 AM John Levine <[email-masked]> wrote:

> In article <CAOEezJSQ=
> [email-masked]> you write:

-- 
Best Regards,

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Sun, 6 Jan 2019 06:07:43 +0530

> For one thing, it doesn't work with IDNs.

I just tested "26pref-español.mydomain.com
<http://xn--26pref-espaol-skb.mydomain.com>" in this page
<https://www.verisign.com/en_US/channel-resources/domain-registry-products/idn/idn-conversion-tool/index.xhtml?loc=en_US>
.

The output looks like "xn--26pref-espaol-skb.mydomain.com". So instead of
"if string starts with", we should go for "if string contains".

On Sun, Jan 6, 2019 at 5:48 AM Viruthagiri Thirumavalavan <[email-masked]>
wrote:

> *So now SMTP clients can check for whether MX server starts with the
> string "26pref". If it starts with that string, then the clients gonna
> connect to port 26 (smtps). A normal client that doesn't know what "26pref"
> stands for gonna connect to port 25 as usual.*
>
> Thanks
>

-- 
Best Regards,

---

From: Alice Wonder <[email-masked]>
Date: Sat, 5 Jan 2019 16:55:59 -0800

On 1/5/19 7:50 AM, Viruthagiri Thirumavalavan wrote:
> server and the latter requires DNSSEC

Hi,

While it is true MTA-STS requires a web server, it can be a static host 
and does not need to be run on same IP / host as the SMTP server.

There are plenty of lightweight free daemons out there that can securely 
serve static content over TLS.

For those who do not yet implement DNSSEC it is a very easy solution and 
is not a barrier to advertising that MTA clients should use TLS when 
connecting and require they use a validating certificate.

---

From: "John Levine" <[email-masked]>
Date: 5 Jan 2019 20:08:28 -0500

>"if string starts with", we should go for "if string contains".

IDNs use a complex encoding and there is no reason to assume the encoding
won't occasionally include the string "26pref".

Really, this is what SRV is for.  It's not hard to program, and we all
know that mail is not the web and the time for DNS lookups (of which
there are already at least two, more if there's multiple MX) is not in
the critical path.  If you want to be clever, do the SRV and MX
lookups at the same time.

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Sun, 6 Jan 2019 08:14:54 +0530

> serve static content over TLS.

Alice, Thanks for the input.

I don't think "lightweight" is the problem here. If i'm desperate about
email security I'm gonna configure the web server even if it is not
lightweight. As you know, web server and mail server are two different
things. One should not depend on another in order to work.

For example, I'm using my domain only for mailing purposes. If I have to
setup a HTTPS server to make my email secure, i'm probably ok with that.
But it's not easy for non-tech savvy user who depends on third party mail
services like Google Apps. Setting up web server, installing SSL
certificates are high level tasks for a non-tech savvy user.

> won't occasionally include the string "26pref".

As far as I can see, the converter converts the IDN names to ASCII string.
Since the text "26pref" is already an ASCII string, it's being kept
untouched.

If you are 100% sure that IDN gonna remove the string, then I agree my
proposal has no merits and this discussion is pointless. But the question
is, are you really 100% sure that they are gonna strip that string?

> lookups at the same time.

In my document, I mentioned this.

*From 2031 onwards, both port 26 and 25 would function similarly. Some
server admins just prefer to deal with only the secure version. So they can
name the MX server with prefix "26only-"*

And this

*In HTTPS, you prepend the "https" in the URL like https://www.google.com
<https://www.google.com> to signal the port 443 existence.*

*In my solution you are doing the same thing. Originally I wanted to have
the "smtps" prefix. So the MX record would look like this.
smtps-mx1.example.com <http://smtps-mx1.example.com>*

*But SMTP doesn't have any redirect feature like HTTP. So I had to go for
variations like "26pref" and "26only". Thus, "port 25 not allowed"
signaling can happen during the MX server "discovery" stage itself.*

Ok John, Let's go with your SRV solution. How can server admins let the
world know that they discontinued port 25?

---

From: Alice Wonder <[email-masked]>
Date: Sat, 5 Jan 2019 19:05:12 -0800

> things. One should not depend on another in order to work.

Well since SMTP is point to point, if you depend upon encryption you 
need S/MIME or PGP and always will.

Also I seem to recall talk of an e-mail header clients can add that tell 
a MTA not to forward it without encryption.

What the HTTPS server in MTA-STS really does is give some limited 
protection against DNS MX record spoofing for zones that do not have 
DNSSEC and/or for MTA clients that do not validate DNSSEC.

SMTP itself still works without running a web server. The web server 
really is just an easier way than DNSSEC for some admins to secure the 
MX response, a 2FA on the MX response so to speak.

> But it's not easy for non-tech savvy user who depends on third party 
> mail services like Google Apps. Setting up web server, installing SSL 

Not really all that high level, and if they are too high level for the 
user, there are inexpensive services that do it for you, including valid 
certificate thanks to Let's Encrypt.

I agree it would be better if Google started signing their zones and 
supported DANE for TLS.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 5 Jan 2019 22:13:45 -0500

> "Security Considerations" section. My proposal is all about deprecating

I stand by the "has no merit" assessment.  Nobody is going to turn
off port 25 support overnight.  This proposal would need to be able
to coëxist with the traditional port 25 SMTP service, but then it is
trivially vulnerable to the same downgrade attacks that it ostensibly
tries to avoid by using "implicit TLS" instead of "STARTTLS".

Indeed STARTTLS gives MTAs the opportunity to decline service prior
to completing the TLS handshake, which can be useful when the client
is e.g. listed on an RBL, or is performing TLS handshakes at an
excessive rate.

Secure MTA-to-MTA SMTP does not require abandoning STARTTLS.  Rather,
MTA-to-MTA SMTP security requires a downgrade-resistant signal of
when TLS is mandatory, and a robust means to authenticate the peer.
Neither of these is facilitated by this proposal.

-- 
	Viktor.

P.S.  Everyone is of course free to post to the list some plausibly
(or even vaguely) on-topic content, and all posts made in good faith
are welcome.  That said, I will not make any further comments in
this thread, as it rather looks like a dead-end.

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Sun, 6 Jan 2019 09:02:30 +0530

> off port 25 support overnight.

I presume you didn't read my document. It's all about turn off port 25 ten
years from the standard publication date. Not overnight.

This proposal would need to be able
> tries to avoid by using "implicit TLS" instead of "STARTTLS".

Sure it can co-exist.

I had this part.

So let me amend that part

*The "26pref" says "We prefer if you connect to our SMTPS in port 26. But
we also accept mails in port 25. And our port 25 supports
Opportunistic TLS. So if STARTTLS command not found in the EHLO response or
certificate is invalid, then drop the connection".*

Basically that means, who ever opt for "Implicit TLS" must also make sure
that they have "Opportunistic TLS" with valid SSL certificate on port 25.
Thus the client can decide either speak securely or don't speak at all.

On Sun, Jan 6, 2019 at 8:43 AM Viktor Dukhovni <[email-masked]>
wrote:

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

-- 
Best Regards,

---

From: "John Levine" <[email-masked]>
Date: 5 Jan 2019 22:59:06 -0500

>years from the standard publication date. Not overnight.

Sorry, but this is a fantasy.  SMTP routing still falls back to an A
record if there's no MX and the DNS has been around for 30 years.  And
your assmptions about what is hard and what is easy may be correct for
your personal situation, but they are not true in general.

Look at it this way -- if you can set up an STS server in less than a
decade, you're ahead of the game.

R's,
John

---

From: Grant Taylor <[email-masked]>
Date: Sat, 5 Jan 2019 21:55:41 -0700

> a MTA not to forward it without encryption.

I'd be curious to know what said header is, and what MTAs support / 
honor it.

> DNSSEC and/or for MTA clients that do not validate DNSSEC.

What‽  That's contrary to my understanding of what MTA-STS is.

My understanding of MTA-STS is that it's a way for receiving domains to 
indicate that they support and want connections to their receiving MTAs 
to use STARTTLS encryption.  Thus sending MTAs can deduce that there is 
a problem if they don't see STARTTLS as an extension when connecting to 
said receiving MTAs.

It seems to me that DNSSEC has little to do with MTA-STS.  In fact, 
DNSSEC is only listed four times in RFC 8641.  Further, MX records can 
pass DNSSEC validation just fine and still be subject to route hijacks 
and the likes.  Said attacks can downgrade SMTP by removing the STARTTLS 
EHLO option, all without running afoul of DNSSEC.

It's my understanding and belief that MTA-STS would continue to protect 
/ detect such manipulation of STARTTLS in such an attack.

What I'm not sure of is if MTA-STS will help detect certificates from 
alternate CAs that allow the attacker to falsely claim to be the 
receiving MTA.  (I need to do more reading.)

> MX response, a 2FA on the MX response so to speak.

Apples and hammers.  (Not even two types of fruit.)

How does DNSSEC secure the MX (response)?  -  Sure, DNSSEC can validate 
that the MX and associated A / AAAA records for a domain have not been 
tampered with.  But that does nothing to ensure that someone isn't 
tampering with STARTTLS.

Or were you alluding to DANE (which requires DNSSEC) and MTA add-on 
software checking for certificate information in DNS to determine if 
STARTTLS should be used and it's absence an indication of a problem?

> certificate thanks to Let's Encrypt.

I'm going to agree with Viruthagiri on this one.  Setting up a web 
server, including TLS certificate, is more advanced than many people are 
comfortable with.  Granted, all of the requirements / steps involved are 
relatively simple in and of themselves.  There are more than a few of 
them, any one of which can be problematic for someone who is completely 
new to doing such.

Don't let your familiarity / comfort of a task cloud the complexity of 
the task.

> I agree it would be better if Google started signing their zones and 

I don't foresee Google using DNSSEC or DANE any time soon.  Much less 
using information that receiving domains publish in conjunction with 
STARTTLS.

-- 
Grant. . . .
unix || die

---

From: Alice Wonder <[email-masked]>
Date: Sat, 5 Jan 2019 21:22:57 -0800

On 1/5/19 8:55 PM, Grant Taylor wrote:
>> Also I seem to recall talk of an e-mail header clients can add that 
>> tell a MTA not to forward it without encryption.
> 

The https part contains a list of MX hosts (or regex of them).
The MTA client is suppose to only use a MX host that is in both the MX 
record and the mta-sts https delivered policy.

Yes it also then requires TLS (and I believe TLS 1.2+ but not positive) 
with a PKI validating certificate, but (assuming enforce mode) it is 
only suppose to communicate with MX hosts that are an intersection of 
what is in the MX record and the https delivered policy.

So the https delivered policy is a 2FA for the MX record that is secured 
by TLS via PKI validation.

TLS is then used to mitigate MITM attacks but if it was just to turn on
TLS all that would be needed is the MTA-STS DNS record.

The web server component secures the MX record.

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Sun, 6 Jan 2019 10:53:12 +0530

> them, any one of which can be problematic for someone who is completely

Finally there is one person agree with me on something. Your response is a
sight for sore eyes mate.
Anyone else wanna join me? I don't think SMTPS will be introduced anytime
soon if you guys are silent.

Don't get me wrong. I don't want to standardise a flawed solution. That's
the last thing I want to do.  However if my solution really makes sense,
then it can make a difference to the SMTP world.

@Viktor Dukhovni

Because of your criticism, I improved my solution. Credit goes to you.  Thanks
very much for that

@John

Your new criticisms are most welcome. But I'm not sure whether your old
criticisms are valid.

> won't occasionally include the string "26pref".

Can you provide an example where it's not the case?

> decade, you're ahead of the game.

Here is the problem with that part.  A records are IE6 equivalent in the
SMTP world. These days everyone moved to the MX records. There are rare
cases where some mail servers still rely on A records.

My solution doesn't deal with A records. It's the clients decision whether
to use MX record or A record.

Let's just pretend my solution rely on A records, you are criticising my
work saying that 0.1% people not gonna upgrade to "MX Records". On the
other hand, you think 100% of the internet gonna upgrade to a completely
new system STS.

Isn't that irony?

---

From: Alice Wonder <[email-masked]>
Date: Sat, 5 Jan 2019 21:28:52 -0800

On 1/5/19 9:22 PM, Alice Wonder wrote:
>> My understanding of MTA-STS is that it's a way for receiving domains 
>> to indicate that they support and want connections to their receiving 
>> MTAs to use STARTTLS encryption.  Thus sending MTAs can deduce that 
>> there is a problem if they don't see STARTTLS as an extension when 
>> connecting to said receiving MTAs.
> 

What I am trying to say -

Requiring TLS is pointless if the MX record is not secure.
That's why MTA-STS needs the https component, to secure the MX record 
when DNSSEC is not used to do so.

When DNSSEC is used, DANE then is better at securing the connection so 
MTA-STS is only needed when the server and/or client do not support DANE 
for SMTP. And the MTA-STS RFC specifically says it is not to be used to 
green light a connection when DANE validation is available but fails.

---

From: Grant Taylor <[email-masked]>
Date: Sat, 5 Jan 2019 22:54:34 -0700

> Requiring TLS is pointless if the MX record is not secure.

I'm inclined to disagree.  -  I see value in requiring TLS via STARTTLS 
even if the MX record wasn't secured.  -  I say inclined because I can't 
articulate the combinations of unmodified / modified MX record in 
conjunction with all the other possibilities that connections can be 
tampered with.  Be it hijacking / route poisoning / simply filtering out 
STARTTLS but not altering anything else.

> for SMTP.

I disagree.

I believe the value of MTA-STS (and HSTS) is the ability to signal that 
SMTP (HTTP) should -ONLY- be conducted over a secure connection via 
STARTTLS (TLS).  Meaning that SMTP (HTTP) should fail if there isn't a 
secure connection.

The signaling of this fact is what makes MTA-STS so valuable to me.  To 
me, the other aspects of DNSSEC / HTTPS are simply infrastructure 
necessary to enable delivery of the STS signal.

-- 
Grant. . . .
unix || die

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Sun, 6 Jan 2019 11:28:04 +0530

> Requiring TLS is pointless if the MX record is not secure.

Alice,

If the DNS is not secure, then that's a completely different issue. It
should be fixed in the DNS rather than SMTP. And that's the reason DNSSEC
was introduced, right?.

Your whole assumption here is MX records are not secure. And guess what...
By that assumption, we shouldn't use email at all for communication. You
should also read this interesting article "where are all the helicopters?
<https://dyn.com/blog/is-dnssec-adoption-worth-it-for-enterprises/>"

MTA-STS is still relying on TXT record for caching. So MTA-STS is more of a
duct-tape solution rather than a bulletproof solution.

And one more issue with this solution is that, why protect only the
senders? Why not receivers? The spoofing prevention records like SPF, DKIM
and DMARC are still not secure, right?

-- 
Best Regards,

---

From: Alice Wonder <[email-masked]>
Date: Sat, 5 Jan 2019 22:11:00 -0800

> STARTTLS but not altering anything else.

It would only help with passive attacks. The MX host is quite often 
completely unrelated to the mailbox domain, so if you cam MITM the DNS 
query you can feed it any MX answer you want that has a PKI validating 
certificate and the MTA client has no reason to reject it.

>> MTA-STS is only needed when the server and/or client do not support 
>> DANE for SMTP.
> 
> I disagree.
> 

Right, but SMTP does not involve a human user to look at the MX response 
and see that it makes sense. The MX record is accepted as valid. DNSSEC 
and the https component of MTA-STS provide two different approaches for 
the MTA client to programmaticly validate the MX response.

---

From: Alice Wonder <[email-masked]>
Date: Sat, 5 Jan 2019 22:13:36 -0800

On 1/5/19 9:58 PM, Viruthagiri Thirumavalavan wrote:
> should be fixed in the DNS rather than SMTP. And that's the reason 
> DNSSEC was introduced, right?.

That's why I use DNSSEC.

But MTA-STS provides a way to leverage PKI to secure the MX record when 
DNSSEC validation is not available. That can be either because the 
receiving domain is not protected by DNSSEC or because the sending MTA 
is not able to validate DNSSEC.

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Sun, 6 Jan 2019 14:27:36 +0530

Maybe my solution should be combined with STS?

The way I see it my solution should be the default way of signalling.

If the MX hosts ends with the same domain (i.e. Self Hosted) and starts
with "26pref", then it's already safe from downgrade attacks. Since the
email address domain matches MX host, domain certificate is safe too.

If the MX hosts ends with different domain (i.e. Third-Party hosted) or
Self-Hosted MX records doesn't start with "26pref", that means it's
vulnerable to MITM attacks. As Alice mentioned we need 2FA in this case.
Website owners can opt-in for STS. And clients should check mta-sts.txt
file existence before transferring the mail.

The advantage of my solution is that, it brings the "Implicit TLS" into
SMTP via a dedicated port. So offers "better security" than STARTTLS. When
both domains and clients opt-in for STS, it offers "ultimate security".

STS believes STARTTLS should be used everywhere. So it asks domains and
clients to opt-in for STARTTLS.

My solution believes SMTPS should be used everywhere. If your MX host is
not self-hosted and doesn't start with "26pref", then it considers those
records are vulnerable to MITM attacks. So security is the default here.
Abnormal records are non-secure. Thus requires 2FA via STS.

Let me know your thoughts.

-- 
Best Regards,

---

From: Jim Fenton <[email-masked]>
Date: Sun, 6 Jan 2019 12:20:18 -0800

> need S/MIME or PGP and always will.

Yes, and remember that S/MIME and PGP only encrypt the message body.
There's still quite a bit of information in the message header and SMTP
transaction that aren't covered.

> tell a MTA not to forward it without encryption.

That's REQUIRETLS, which does this with an SMTP option rather than a
header field (there is also a header field for the opposite request, to
ignore MTA-STS and DANE).

https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-require-tls/

-Jim

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Mon, 7 Jan 2019 13:49:30 +0530

Hey all, revised my draft based on the feedback I received from this
thread.

Changelog:

* Added starttls only support.
* Provided test cases for IDN names.
* Included Jim Fenton's proposal in the related projects section.
* No port hardcoding. Removed 26pref and 26only options. Now MX hosts can
start with either "smtps-" or "starttls-" prefix
* Solution can be used along with STS and DANE

Thanks

-- 
Best Regards,

---

From: Alice Wonder <[email-masked]>
Date: Mon, 7 Jan 2019 01:11:31 -0800

Rather than use a hostname to specify SMTPS only, how about a DNS TXT 
record to indicate SMTPS only?

And if that DNS TXT record exists, rather than waste a < 1024 port 
number, just have the MTA client use Port 25 with STARTTLS required.

Then it is just like MTA-STS except w/o the HTTPS component that secures 
the MX record.

But bottom line is to be RFC compliant, an MX host MUST accept on Port 
25 without encryption.

The MTA client decides whether or not it wants to send without an 
encrypted session, the server MUST accept if the client chooses to 
connect without encryption.

The MX server already has two different ways it can advertise to MTA 
clients they can safely require the connection to be secure, DANE for 
SMTP and MTA-STS. Both of those ways secure the MX record.

All you proposal seems to be offering is MTA-STS without a mechanism to 
secure the MX records.

I'm perfectly with the recommendation that MTA clients require a secure 
connection if the DNS component of MTA-STS is present but the HTTPS 
component is not there.

In fact I'm perfectly fine with MTA clients that refuse connections that 
do not offer STARTTLS regardless of whether the other server offers 
MTA-STS or DANE.

I already do that! On web servers that are MTA client only. When a 
web-app user does a password reset, or anything else web-app account 
related, I do not want it modified in transit allowing easy NSA (or 
other) phishing access. So the receiving MX supports STARTTLS or the 
message is not sent.

I don't need a different port number for that. And honestly it has never 
been a problem, never had a user account use an e-mail where the MX 
server did not offer STARTTLS. I'm sure they exist, but are not common.

I just don't see a need for what is proposed. I do not understand the 
problem it solves. And securing the MX record (via DNSSEC or MTA-STS) is 
something that SHOULD be encouraged, whether or not you are aware of 
helicopters (helicopters is reference to link that argues DNSSEC isn't 
really needed because some military Generals didn't like technology that 
shot down helicopters)

On 1/7/19 12:19 AM, Viruthagiri Thirumavalavan wrote:
> * No port hardcoding. Removed 26pref and 26only options. Now MX hosts 
> can start with either "smtps-" or "starttls-" prefix

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Mon, 7 Jan 2019 15:39:41 +0530

Alice thanks for the insight.

> record to indicate SMTPS only?

Third party mail hosting services usually provide services for millions of
domains. You are asking those millions of people to go for 1 more step. I'm
asking that step should be embedded in the mx hostname. Users should do the
steps as they did before, but now the mx records contains smtps prefix.

> But bottom line is to be RFC compliant, an MX host MUST accept on Port

You are worried about wasting a port. But I'm worried about bringing full
possible encryption to the SMTP.  I have never heard of many of the
services found in < 1024 ports. You maybe too. So i'm pretty sure IANA ok
with assigning a new port to SMTPS.

My proposal is to being "Implicit TLS" to the SMTP relay. If you don't
allocate a new port, then people are not going to take the solution
seriously. And as you mentioned, an MX host MUST accept on port 25 without
encryption. So you can do all the hack you want like STARTTLS, port 25 is
never gonna be treated as a fully secure protocol. Via STARTTLS we are
trying to provide "best effort" security. SMTPS can provide "Full effort"
security. That's the maximum possible security we can provide. Top to
bottom everything encrypted. We all moved to HTTPS today.  It will take
many decades to completely move to SMTPS. Maybe 20 years. But if we worry
about wasting a port today, then it's gonna take forever.

> SMTP and MTA-STS. Both of those ways secure the MX record.

Both STS and DANE are not a solution for non-tech savvy folks. I'm gonna
hold-on to that point. My solution primarily try to deal with the SMTP
security. But I also incorporated STS and DANE as 2FA as you mentioned in
my revised proposal. But I made them optional. Not mandatory. If you make
them mandatory, then people are not gonna adopt due to its complicated
nature.

> secure the MX records.

In my updated proposal, I mentioned that you can use either STS or DANE to
protect MX records. I even gave example there.
https://gist.github.com/mistergiri/a4c9a5f1c26fd7003ebc0652af95d314#2fa

> problem it solves.

It tries to make everyone upgrade to a new secure protocol in the long run.
But also tries to protect the STARTTLS downgrade attacks. As for
authentication, it leaves the job to both STS and DANE

-- 
Best Regards,

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 7 Jan 2019 11:46:23 +0100 (CET)

> Il 7 gennaio 2019 alle 9.19 Viruthagiri Thirumavalavan <[email-masked]> ha scritto:
> 
>     Hey all, revised my draft based on the feedback I received from this thread. 
> 
>     Changelog:
> 
>     * No port hardcoding. Removed 26pref and 26only options. Now MX hosts can start with either "smtps-" or "starttls-" prefix
Hello,

I remember you from a few months ago on the DMARC-discuss list, when you tried to convince everyone that you had finally solved the problem of spam by introducing your proprietary standard "Sender Alias Domains" (where did that go?). So while I appreciate your ingenuity and willingness to approach big problems that are not completely solved yet, I must also point out that there are good reasons why those problems have not been addressed with easy solutions like the ones you propose. I would advise you to make sure that you fully appreciate the explanations that are given to you on why your proposal is fundamentally flawed, rather than just adjusting the original proposal a bit and keep posting it again.

Specifically, adding whatever semantic value to DNS hostnames or parts thereof is a non-starter for many reasons that have already been pointed out, so please stop proposing that. Moreover, the IETF does not have the power to mandate people to turn on or off specific services at a specific time, nor to change or update their implementations, neither in theory (in regulatory terms) nor in practice, so any proposal should be backwards compatible with the status quo for an indefinite amount of time. So, in the end, your solution fails to prevent downgrade attacks, but even if it did, they have been addressed with two other technologies already (MTA-STS and DANE), so there is really no reason to develop a third one unless you can provide a compelling reason or use case in which both the other two do not work.

On that point, you are right when you say that big systems that host mail for thousands or millions of domains are unlikely to ever implement MTA-STS, as that requires to activate one HTTP service per each domain - but we already have DANE for that case.

Regards,

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Alice Wonder <[email-masked]>
Date: Mon, 7 Jan 2019 02:50:25 -0800

On 1/7/19 2:09 AM, Viruthagiri Thirumavalavan wrote:
> Third party mail hosting services usually provide services for millions 
> of domains. You are asking those millions of people to go for 1 more 
> step. I'm asking that step should be embedded in the mx hostname. Users 
> should do the steps as they did before, but now the mx records contains 
> smtps prefix.
> 

They already will query for the existence of the MTA-STS record, and 
likely have unbound or similar caching resolver running on the localhost 
or at least at same hosting facility that caches the response to the query.

Why not just require STARTTLS if the TXT record for 
_mta-sts.example.org. exists? They check for that anyway.

> You are worried about wasting a port. But I'm worried about bringing 
> full possible encryption to the SMTP.  I have never heard of many of the 
> services found in < 1024 ports. You maybe too. So i'm pretty sure IANA 
> ok with assigning a new port to SMTPS.

I do want full possible encryption brought to SMTP. This is why I 
encourage DANE for SMTP with MTA-STS as a backup for servers / clients 
that do not implement DANE for SMTP.

The problem is solved.

> seriously. And as you mentioned, an MX host MUST accept on port 25 
> without encryption. So you can do all the hack you want like STARTTLS, 
> port 25 is never gonna be treated as a fully secure protocol. Via 
> STARTTLS we are trying to provide "best effort" security. SMTPS can 
> provide "Full effort" security. That's the maximum possible security we 
> can provide. Top to bottom everything encrypted. We all moved to HTTPS 
> today.  It will take many decades to completely move to SMTPS. Maybe 20 
> years. But if we worry about wasting a port today, then it's gonna take 
> forever.

You are missing the point.

It is up to MTA client to decide whether or not encryption should be 
required. You can have your MTA client do that today, right now, without 
needing to use a different port.

What you want is a client that gets its cue to go into that secure only 
mode from the MX record, but that is an easily defeated trigger if the 
MX record is not secured.

There are two ways to secure the MX record - DNSSEC and MTA-STS, both of 
which then already require STARTTLS without needing a new port assigned.

There is also the STARTTLS Everywhere project which provides a GPG 
signed json file of hosts you should require STARTTLS with. It is fairly 
easy to turn that JSON fine into a Postfix policy map, I assume the same 
applies to other MTA clients. That is a good temporary solution while 
software/admins catch up with implementing DANE and MTA-STS in the MTA 
clients and servers. And it does not require a new port.

Port 26 gives us nothing that a policy map file with domains we know 
should require STARTTLS does not also give us.

How about instead of designating a new port, a "best practices" RFC is 
created suggesting that MTA clients require STARTTLS when the the 
MTA-STS record exists, whether or not the policy file can be 
successfully retrieved by HTTPS?

That will allow system administrators who are having trouble setting a 
web server for the MTA-STS policy file to still advertise they have set 
up TLS on their mail server.

How about this:

When the MTA-STS DNS record has a serial number of 0 *and* 
mta-sts.example.org domain name does not have an A or AAAA record, then 
the MTA client SHOULD still require STARTTLS.

That would allow MTA clients to know they should at a minimum require 
STARTTLS with mail sent to that domain, it would not require any DNS 
queries beyond what is already required, and it would not require DNSSEC 
or a HTTPS web server.

But MX admins should still do both DANE and MTA-STS whenever possible to 
secure the MX record.

---

From: Alice Wonder <[email-masked]>
Date: Mon, 7 Jan 2019 03:36:50 -0800

On 1/7/19 2:46 AM, Vittorio Bertola wrote:

> 
> On that point, you are right when you say that big systems that host 
> mail for thousands or millions of domains are unlikely to ever implement 
> MTA-STS, as that requires to activate one HTTP service per each domain - 
> but we already have DANE for that case.
> 

Additional note on this.
I and many others already have policy maps requiring "secure" (starttls 
+ PKI validating certificate) connection to the "major" providers of 
third-party mail services.

If someone did create a "BEST PRACTICES" RFC intending to increase 
required TLS on sending where appropriate, that practice should probably 
be included. That protects most instances involving third party mail 
providers.

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 7 Jan 2019 13:22:50 +0100 (CET)

>     Il 7 gennaio 2019 alle 12.36 Alice Wonder < [email-masked] mailto:[email-masked] > ha scritto:
> 
> 
You should also accept the other flavour of "secure" (starttls + DANE + any certificate matching the DANE records, even a self-signed one), though major providers will use PKI-validating certificates anyway, even with DANE. Also, without DANE, a PKI-validating certificate is not enough if you don't check that the hostname in the certificate matches the intended destination. I'm sure you know, but just for the sake of completeness, if anyone actually wanted to write a best practice document...

Regards,

--

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Mon, 7 Jan 2019 17:53:59 +0530

@Vittorio Bertola

I'm trying to help the IETF community in the way I can. Of course I'm gonna
revise my work and ask for feedback. That's what this mailing list is for
right? If the mailing list terms says that I should not ask feedback upon
improving my work, then yes what I'm doing is wrong.

You didn't put any effort to help me, yet you think you have the right to
attack me on a public forum? Do you really think I'm spending my time here
for my personal gain?

It seems like your intention here is to attack me based on my few months
old post. You also seem quite confident that I lied there without even
going through my paper. If you had completed my paper, then you wouldn't be
so cocky here.

Ok you won. I'm gonna leave this mailing list because you feel annoyed here
because of me.

My only question here is, how confident are you that my spam solution never
gonna work? e.g. I would give you a million dollar if it works, I would
kill myself if it works etc.

You also seem like a honourable man. So I believe you would honour your
words if my spam solution really work.

Before you give your word, you should know this is what investors think
about my work.
https://www.dropbox.com/s/599s5iz25h1d680/Screenshot%202019-01-07%2017.12.11.png?dl=0

And that's coming from an engineer turned investor who have experience in
mail servers. So I'm not trying to rip off innocent investors. That
investor turned me down because my solution requires bigger bets. So yeah
just because I don't have a billion dollar company in few months doesn't
mean my solution failed. It means I'm still trying to find an investor who
is ready to go through my 300 pages research paper.

You might have had some respect for me and my work, if you really had gone
through the presentation I posted on that day. I really hate guys like you.
Because guys like you act like "know-it-all" and the guys like me are the
victims.

@Alice Wonder

You are really a nice person and it's really an honour to have discussion
with people like you.

I was actually working on my product. When you are working with SMTP, you
definitely know the SMTP problems. I noticed the STARTTLS downgrade issue
not addressed properly. And I felt both STS and DANE are overkill for an
average user. So I signed up to this mailing list and posted my proposal. I
have other proposals too for SMTP. But I don't think guys like Vittorio
gonna appreciate my work until I gain some public reputation. To their eyes
I'm a overconfident idiot.

So I'll leave this mailing list for now. But I love to have a discussion
with people like you. So I'll collaborate with you someday.

@Everyone

Thanks for helping me. It means a lot. Good luck

-- 
Best Regards,

---

From: Alice Wonder <[email-masked]>
Date: Mon, 7 Jan 2019 04:42:18 -0800

On 1/7/19 4:22 AM, Vittorio Bertola wrote:
> 
>> Il 7 gennaio 2019 alle 12.36 Alice Wonder < [email-masked] 
>> <mailto:[email-masked]>> ha scritto:
>>
>>
> You should also accept the other flavour of "secure" (starttls + DANE + 
> any certificate matching the DANE records, even a self-signed one), 
> though major providers will use PKI-validating certificates anyway, even 
> with DANE. Also, without DANE, a PKI-validating certificate is not 
> enough if you don't check that the hostname in the certificate matches 
> the intended destination. I'm sure you know, but just for the sake of 
> completeness, if anyone actually wanted to write a best practice 
> document...
> 
> Regards,

I most certainly do. I prefer DANE. PKI is high maintenance, you have to 
frequently update your trusted root anchors.

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 7 Jan 2019 15:24:38 +0100 (CET)

> Il 7 gennaio 2019 alle 13.23 Viruthagiri Thirumavalavan <[email-masked]> ha scritto:
> 
>     @Vittorio Bertola
> 
Hello,

it looks like you misinterpreted my reply completely, reading things in it that I never thought or said, but in any case, if you felt offended by it, I apologize. I actually think that the IETF is often too unwelcoming and rude to new participants and I do not want to be part of that attitude at all. At the same time, though I actually praised your boldness in repeatedly trying to tackle big issues, the consensus seems to be that your proposal cannot be supported, no matter how much you fix it, and so there is not much help we can give you, other than explaining to you the technical reasons for that conclusion, as I did in my reply; please accept the conclusion without taking it as a personal attack.

Regards,

--

---

From: Alice Wonder <[email-masked]>
Date: Mon, 7 Jan 2019 06:42:10 -0800

On 1/7/19 6:24 AM, Vittorio Bertola wrote:
> it looks like you misinterpreted my reply completely, reading things in 
> it that I never thought or said, but in any case, if you felt offended 
> by it, I apologize. I actually think that the IETF is often too 
> unwelcoming and rude to new participants and I do not want to be part of 
> that attitude at all. At the same time, though I actually praised your 
> boldness in repeatedly trying to tackle big issues, the consensus seems 
> to be that your proposal cannot be supported, no matter how much you fix 
> it, and so there is not much help we can give you, other than explaining 
> to you the technical reasons for that conclusion, as I did in my reply; 
> please accept the conclusion without taking it as a personal attack.
> 

Hear hear, and I share the passion too.

If it were up to me, an RFC would be published deprecating opportunistic 
TLS for SMTP.

System administrators would have three years, but after that, TLS 1.3+ 
would be required for SMTP.

Reason for TLS 1.3+ is that it requires ciphers with forward secrecy.

But I know it will never fly. It's what I want though.

---

From: Daniel Margolis <[email-masked]>
Date: Mon, 7 Jan 2019 17:29:19 +0100

Yeah, I wanted to chime in on this thread to say something similar. ;)

I have always admired how modern browsers have been able to really push the
boundaries on security UI (e.g. showing warnings for weak ciphers, etc) and
consequently change the state of security for most of the Web ecosystem. I
would (speaking personally here) love to see major mail providers do
something similar to what Alice said and sunset weak (unencrypted, or
unauthenticated) SMTP.

But there are, I think, at least two ways in which mail is somewhat
different than the Web for this:

1. There's no great *synchronous* UX to show users auth failures or
downgrades and get them to approve, nor do identifiers even indicate an
expected state of security. (Users who enter "https" manually--which
admittedly is probably a very rare behavior--are explicitly indicating
something akin to Require-TLS, whereas email traditionally has no such
indicator; more importantly, perhaps, there's no great mechanism to show
users "we tried STARTTLS but couldn't negotiate it; do you want to
continue?" since mailing is async.)

2. Mail is quite commonly outsourced to a hosting provider, so you can't
just require server identities to match the @domain--you need to somehow
validate the MX.

Admittedly both of these problems are fixable with existing technologies: a
Webmail provider could check for DANE and DNSSEC on the MX zone and warn
users at message compose time where it's not present, for example. But it
does feel to me hard to shoehorn this into the SMTP ecosystem as it
currently exists, though perhaps we're all just too incrementalist or
something.

I do see improvements, however--notably, that opportunistic TLS is now very
common, DANE is of increasing usage, and MTA-STS hopefully provides an
alternate for those who cannot adapt DANE, and Require-TLS is an experiment
in giving users that UI control. So I think things are moving in the right
direction.

Viruthagiri, I appreciate the bold suggestions. New things would never
happen without them! If people are a little crusty sometimes, I think it's
only feedback about the difficulty of fully understanding context and
history when making a new proposal.

Dan

-- 
How's my emailing? http://go/dan-email-slo

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Tue, 8 Jan 2019 01:21:50 +0530

@Daniel Margolis

Thanks for the input. Really appreciate that.

@Vittorio Bertola

My apologies for being rude earlier. I was little upset when I saw your
post. I'm okay now. Again my apologies. I had to defend myself there.

I remember you from a few months ago on the DMARC-discuss list, when you
> tried to convince everyone that you had finally solved the problem of spam
> by introducing your proprietary standard "Sender Alias Domains" (where did
> that go?).

When you say something like that on this list, you are implying like "Hey,
this guy is not serious. You are wasting your time by helping him". And
that's much worse than the guys who attacked me on the DMARC list.

I think I already made it pretty clear. Trying to standardise a flawed
solution is the last thing I wanna do. So I have no problem if my proposal
get rejected due to flaws. But not because we already have STS and DANE.

This is how you responded

I would advise you to make sure that you fully appreciate the explanations
> that are given to you on why your proposal is fundamentally flawed, rather
> than just adjusting the original proposal a bit and keep posting it again.

I posted in ietf-smtp and this is how they responded

Especially if you are new, please interpret my response (and
> those of several others) as "we aren't convinced about your
> idea" or "we think there are better alternatives", not as "your
> proposal is bad and will cause problems".   I'd like to see a
> lot more discussion before the latter conclusion is reached
> although I'd encourage you to read the comments carefully and
> see if they suggest ways to improve the proposal.  I believe
> that it is very important that new ideas to which long-time
> participants have initial negative reasons get careful
> consideration and every reasonable chance to succeed before they
> are dismissed.

They even go an extra step to show their hospitality

Also, the IETF functions much better when document proposals are
> posted as Internet Drafts.   See
> https://www.ietf.org/standards/ids/ and
> https://datatracker.ietf.org/submit/tool-instructions/ and the
> other headings on the latter page.   Under normal circumstances,
> I'd volunteer to help you get an Internet-Draft together from
> you github posting but this week is just too busy.  Perhaps
> someone else can help you get started (that is a call for
> volunteers, folks), otherwise please get back to me next week.

welcome to the IETF.

These folks are down to earth. And I would be ready to work with them any
day.

Feel free to criticise my work. I even thanked many people in this list for
that. But please don't insult me just to prove a point.

I'm gonna continue this proposal discussion in ietf-smtp list. I wish you
good luck and my apologies once again for what I said earlier.

Thanks

On Mon, Jan 7, 2019 at 9:59 PM Daniel Margolis <dmargolis=
[email-masked]> wrote:

> I have always admired how modern browsers have been able to really push
> the boundaries on security UI (e.g. showing warnings for weak ciphers, etc)
> and consequently change the state of security for most of the Web
> ecosystem. I would (speaking personally here) love to see major mail
> providers do something similar to what Alice said and sunset weak
> (unencrypted, or unauthenticated) SMTP.
>
> Admittedly both of these problems are fixable with existing technologies:
> a Webmail provider could check for DANE and DNSSEC on the MX zone and warn
> I do see improvements, however--notably, that opportunistic TLS is now
> very common, DANE is of increasing usage, and MTA-STS hopefully provides an

-- 
Best Regards,

---

From: Franck Martin <[email-masked]>
Date: Mon, 7 Jan 2019 14:33:41 -0600 (CST)

----- Original Message -----
> From: "Alice Wonder" <[email-masked]>
> To: "uta" <[email-masked]>
> Sent: Monday, January 7, 2019 6:42:10 AM
> Subject: Re: [Uta] SMTP Over TLS on Port 26 - Implicit TLS Proposal
> 

I feel the pain too.

There is too much operational inertia in the world of email servers. Upgrades take years.

It took years to deprecate RC4. DKIM still uses outdated cyphers, and there are no new ones approved (yet) AFAIK.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 8 Jan 2019 01:50:14 +0000

Alice Wonder <[email-masked]> writes:

>If it were up to me, an RFC would be published deprecating opportunistic TLS
>for SMTP.

Assuming you're actually serious, why?

Peter.

---

From: Alice Wonder <[email-masked]>
Date: Mon, 7 Jan 2019 17:57:21 -0800

> Assuming you're actually serious, why?

I'm a privacy zealot and many people have trouble getting PGP or S/MIME 
to work. I've met Ph.Ds who couldn't figure it out.

Requiring TLS not only gives passive protection, but it also means we 
would have the assumption of privacy when communicating with e-mail 
which at least in the United States has legal ramifications for law 
enforcement snooping on e-mail w/o a warrant.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 7 Jan 2019 18:00:19 -0800

On 1/7/19 12:33 PM, Franck Martin wrote:
> It took years to deprecate RC4. DKIM still uses outdated cyphers, and 
> there are no new ones approved (yet) AFAIK.

See RFC 8463.

-Jim

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 8 Jan 2019 02:55:16 +0000

Alice Wonder <[email-masked]> writes:

>I'm a privacy zealot 

So how would deprecating opportunistic TLS help in that regard?

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 7 Jan 2019 22:17:02 -0500

> On Jan 7, 2019, at 9:55 PM, Peter Gutmann <[email-masked]> wrote:
> 
>> I'm a privacy zealot 
> 

What Alice really meant is deprecating *cleartext* TLS, and with
TLS now mandatory, somehow also getting authentication in place.
This is not about to happen overnight.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 7 Jan 2019 22:42:28 -0500

>record to indicate SMTPS only?

How about a SRV lookup instead of a TXT lookup?  That has the
advantage that it already exists.

---

From: Alice Wonder <[email-masked]>
Date: Mon, 7 Jan 2019 20:01:49 -0800

> So how would deprecating opportunistic TLS help in that regard?

MX servers would not be violating RFC if they rejected plain text 
connection attempts (over 90% of which these days are spam).

MX servers would be violating RFC if they did accept plain text connections.

This will virtually eliminate passive attacks that log non-encrypted 
traffic. The TLS 1.3+ requirement makes it less worthwhile to log 
encrypted traffic because the secrets used for the ciphers are ephemeral.

btw in the 00s I knew a tech at a large silicon valley data center who 
bragged that he logged SMTP traffic and had scripts to look for 
potential insider trading information. Whether he actually did or not I 
do not know, but it is very possible he did.

There are good reasons to encrypt as much as possible.

---

From: "John Levine" <[email-masked]>
Date: 8 Jan 2019 09:57:25 -0500

>connection attempts (over 90% of which these days are spam).

10% is a pretty fat long tail.  The people I know who run production
mail systems are much more concerned about receiving all of the real
mail than rejecting spam earlier.

We went through all of this when we invented MTA-STS.  We know that
setting up a web server can be non-trivial but for a lot of places,
it's far easier than geting DNSSEC to work.  I recall a dinner at the
Buenos Aires IETF where we were trying to figure out if there were a
reasonable way to signal stuff in the DNS.  Magic names certainly came
up.

I think it would be a good idea for anyone interested in this topic to
go back through the mailing list discussion and read the drafts and
explain what is different now that we didn't know when we defined
MTA-STS a few months ago.

R's,
John

---

From: Alice Wonder <[email-masked]>
Date: Tue, 8 Jan 2019 07:17:34 -0800

> mail than rejecting spam earlier.

Yes, I am NOT proposing it because I know it wouldn't fly, but it is 
what I wish for. I simply expressed it to let the person with Port 26 
suggestion know that I too wish for TLS everywhere.

I know in real world it won't happen even though I would very much like it.

What would happen, it would end up being an RFC that is ignored and thus 
serve no purpose. Maybe someday, but not now.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 8 Jan 2019 16:47:36 +0100 (CET)

> Il 8 gennaio 2019 alle 16.17 Alice Wonder <[email-masked]> ha scritto:

Perhaps, at a certain point in the future, we could call a "flag day" and get the biggest email providers in the world to agree and advertise that they will stop accepting and delivering email in cleartext on that day, full stop. But still, I agree with John - the priority is on not losing legitimate email, and it would be hard to convince everyone to sign up (especially managements).

Also, some regulatory push could do a lot, as it would allow operators to turn off cleartext without having to take responsibility for the lost messages. In some drafts of the ePrivacy Regulation (at the European Parliament) there was a requirement for "end-to-end encryption of electronic 
communications"...

In the meantime, many are making efforts to evangelize the industry on DANE and MTA-STS - that's what we can do immediately.

Regards,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 08 Jan 2019 10:40:46 -0500

> would be required for SMTP.

There is precedent for far-reaching flag days for security and
performance changes in protocols that are not directly user-facing:

   XMPP manifesto for authenticated TLS on all connections:
   https://github.com/stpeter/manifesto/blob/master/manifesto.txt

   DNS: requiring authoritative servers to support EDNS queries:
   https://dnsflagday.net/

There's no reason in principle that a well-motivated and well-organized
push for SMTP couldn't have a comparable set of deadlines.  But doing so
will take organizing and technical work to coordinate such a transition.

I think the community would welcome that, but figuring out what specific
timeline is plausible; getting affirmative buy-in; setting up adequate
testing and notice; etc, is the real work involved.  It won't happen
just by wishing it.

    --dkg

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 8 Jan 2019 16:57:57 +0000

Related work:

 https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/
 https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpeno/

-- 
Cheers,
  Jeremy

---

From: "John Levine" <[email-masked]>
Date: 8 Jan 2019 12:26:30 -0500

>testing and notice; etc, is the real work involved.  It won't happen

MTA-STS does a great deal of this.  It has a way for a domain to say
"all my inbound mail uses TLS" (RFC 8461) and for other systems to
report back and say whether they're actually seeing that (RFC 8460.)

I don't understand why people are trying to reinvent the wheel when we
just defined a fairly round one a few months ago.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 8 Jan 2019 18:36:23 +0100 (CET)

> Il 8 gennaio 2019 alle 18.26 John Levine <[email-masked]> ha scritto:
> 
> 

DANE and MTA-STS provide an evolutionary and backwards compatible path for the transition to fully encrypted and authenticated email flows for those that care, but cannot force anyone to care and deploy them. What we are discussing is whether we could collectively exert gentle pressure (i.e. encrypt your email by this date or you won't be allowed to communicate any more) so that even those that don't care start to care.

Regards,
--

---

From: "John R Levine" <[email-masked]>
Date: 8 Jan 2019 12:58:03 -0500

> DANE and MTA-STS provide an evolutionary and backwards compatible path for the transition to fully encrypted and authenticated email flows for those that care, but cannot force anyone to care and d…

The reports from MTA-STS give us a baseline.  It's a lot easier to propose 
a flag day if you can credibly say that 98% of all non-bot mail uses TLS 
now.

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

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 9 Jan 2019 02:29:29 +0000

John Levine <[email-masked]> writes:

>10% is a pretty fat long tail.  The people I know who run production mail
>systems are much more concerned about receiving all of the real mail than
>rejecting spam earlier.

There's also a near-infinite amount of embedded and IoT that uses email to
send out alerts of abnormal conditions, or even just routine status updates.
Getting all that switched to TLS is going to take the lifetime of the
equipment, and possibly the lifetime of its replacement as well.

Peter.