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

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

Hello Everyone,

I have proposal for SMTPS. Already gathered some feedback from UTA working
group and improved my draft.

My proposal is a very simple document. So, please go though it and give
me feedback if you can.

Here is my abstract.

---------
SMTP is still suffering from downgrade attacks like STRIPTLS. While we have
"Opportunistic TLS", we still don't have "Implicit TLS" in the SMTP. Don't
get me wrong. We do have "Implicit TLS" for "SMTP Submission" on port 465.
But we don't have a secure port 25 alternative. i.e. The real SMTPS

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.

This document propose a new port 26, an "Implicit TLS" alternative for port
25 and recommends the MX server to signal the port via a prefix.

e.g. mx1.example.com should be prefixed like smtps-mx1.example.com.

Where "smtps-" 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".
--------

Thanks

-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Mon, 7 Jan 2019 14:02:24 +0530

Oops... Forgot to include the proposal document link.

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

Sorry about that.

On Mon, Jan 7, 2019 at 1:55 PM Viruthagiri Thirumavalavan <[email-masked]>
wrote:

> SMTP is still suffering from downgrade attacks like STRIPTLS. While we
> have "Opportunistic TLS", we still don't have "Implicit TLS" in the SMTP.
> Don't get me wrong. We do have "Implicit TLS" for "SMTP Submission" on port
> 465. But we don't have a secure port 25 alternative. i.e. The real SMTPS
>
> This document propose a new port 26, an "Implicit TLS" alternative for
> port 25 and recommends the MX server to signal the port via a prefix.
>

-- 
Best Regards,

---

From: Gilles Chehade <[email-masked]>
Date: Mon, 7 Jan 2019 09:58:07 +0100

> Hello Everyone,

Hello,

> But we don't have a secure port 25 alternative. i.e. The real SMTPS

465/tcp was already SMTPS, not Implicit TLS.

> server and the latter requires DNSSEC.

Agreed

> is invalid, then drop the connection".

Wouldn't it be simpler to let implementations try 465/tcp first and fall
back to 25/tcp, or use SRV records ?

-- 
Gilles Chehade						       @poolpOrg

https://www.poolp.org                 tip me: https://paypal.me/poolpOrg

---

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

> back to 25/tcp, or use SRV records ?

MX Records are equivalent to SRV records. Refer section 3 of this document.
https://tools.ietf.org/id/draft-ietf-dane-srv-05.html#rfc.section.3
If we are gonna use SRV record to deal with mail related stuffs, then it
beats the purpose of having MX record.

Trillions of mails sent every year. Why do we have to waste trillion of
requests every year in trying for 465 when the signalling step can be
embedded in the mx host name?

Can you give me a good reason, not to go for my solution?
On Mon, Jan 7, 2019 at 2:28 PM Gilles Chehade <[email-masked]> wrote:

> have
> port

-- 
Best Regards,

---

From: Gilles Chehade <[email-masked]>
Date: Mon, 7 Jan 2019 12:13:54 +0100

> Can you give me a good reason, not to go for my solution?

don't know if they're good reasons but there's already 465/tcp for smtps
and I don't know what to think about tying protocol behavior to hostname
as it feels really hackish to me.

I would have high-fived a proposal to do opportunistic smtps, but here I
feel you're hacking behavior by encoding it in a field that's not meant
to carry it.

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

-- 
Gilles Chehade						       @poolpOrg

---

From: Paul Smith <[email-masked]>
Date: Mon, 7 Jan 2019 11:34:05 +0000

> as it feels really hackish to me.

Note that port 465 is defined as for SMTPS for *submission*, so it's the 
SMTPS version of 587, not the SMTPS version of 25.

I agree that using the hostname for this feels hackish. An SRV or TXT 
record would seem more obvious.

I'm not sure of the advantage of implicit TLS over STARTTLS if downgrade 
is prevented, and given that your MTA will have to still accept STARTTLS 
& unencrypted connections for interoperability, it seems a bit 
unnecessary here.

A simple TXT record saying "This domain's MTAs support STARTTLS (and, 
possibly, optionally, this is the certificate fingerprint)" would seem 
useful and not need anything else, and would protect against STARTTLS 
downgrade for any sender willing to support it.

Obviously it would be vulnerable to DNS pollution, but so would the 
original proposal.

-- 

Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 7 Jan 2019 12:03:07 +0000

> downgrade for any sender willing to support it.

Starting to look like a DANE TLSA record...
-- 
Cheers,
  Jeremy

---

From: Paul Smith <[email-masked]>
Date: Mon, 7 Jan 2019 12:08:48 +0000

> Starting to look like a DANE TLSA record...

Yep - but without needing DNSSEC, which seems to be the OP's problem 
with DANE.

--

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Jan 2019 07:33:39 -0500

--On Monday, January 7, 2019 11:34 +0000 Paul Smith
<[email-masked]> wrote:

>...
> A simple TXT record saying "This domain's MTAs support
> STARTTLS (and, possibly, optionally, this is the certificate
> fingerprint)" would seem useful and not need anything else,
> and would protect against STARTTLS downgrade for any sender
> willing to support it.
> 
> Obviously it would be vulnerable to DNS pollution, but so
> would the original proposal.

Please see at least one of Burt Hubert's "DNS Camel" pieces
and/or RFC 8324, and think about not only pollution/cache
poisoning but about the observation that DNS zone managers and
email administrators are often in separate departments with less
effective communication than one might like, before going down
that path.  

<rant> Given some of my other concerns, I also had a quick
thought about some people changing "support" in the above text
to "supports" while others didn't and others writing the whole
string in some language very different from English (the DNS
certainly would not prevent a string in Unicode encoded in UTF-8
from appearing in the DATA of a TXT RR).  Consider what would be
required for an SMTP-Sender to retrieve all of the TXT RRs
associated with a given FQDN and then parse each of them,
possibly through a multilingual language-understanding module,
to see if that was the intended message.   A variety of
subsequent abuses^H^H^H^H^H^H features notwithstanding, there
are rather good reasons why, when the DNS was first designed and
specified, the assumption was that information in TXT records
was intended strictly as information for human consumption, not
for processing by programs.  </rant>

    john

    john

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Jan 2019 07:41:16 -0500

--On Monday, January 7, 2019 15:53 +0530 Viruthagiri
Thirumavalavan <[email-masked]> wrote:

> Trillions of mails sent every year. Why do we have to waste
> trillion of requests every year in trying for 465 when the
> signalling step can be embedded in the mx host name?
> 

Borrowing a bit from the note I sent a few minutes ago (please
read it first), there are efforts all around the world to get
DNS names into local writing systems and compatible with the
writing systems used in local languages -- so-called
"internationalized domain names" or "IDNs"   That effort has
already turned things like 
  www.<label-in-non-latin-script>.<label-in-non-latin-script>
into an ugly mess and invitation to assorted attacks, especially
if that script either looks a lot like Latin or is mostly
written right to left.   Naming conventions have their place and
can be really convenient, but turning them into protocol
elements rather than hints for convenience is just a really bad
idea.

If DNS tricks are needed and useful, use SRV records.

    john

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Mon, 7 Jan 2019 18:12:48 +0530

https://gist.github.com/mistergiri/a4c9a5f1c26fd7003ebc0652af95d314#internationalized-domain-names

-- 
Best Regards,

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Jan 2019 11:01:31 -0500

--On Monday, January 7, 2019 18:12 +0530 Viruthagiri

> 5d314#internationalized-domain-names

I don't know what point you are trying to make, but while IDNA
can handle encoding of non-ASCII domain names to ACE (ASCII
Compatible Form) perfectly well, users tend to respond
negatively to A-label forms (if any of that terminology is
unfamiliar, see RFC 5890).  I did not suggest that such naming
conventions (whether as prefixes to labels or as subdomains)
would not work technically in the DNS, only that encoding
information that implies protocol-level action in DNS labels has
rarely, if ever, turned out to be a good idea.  I also note that
the examples, in which "smtps-' is used at the beginning of a
label that may be in a non-Latin script, are so-called "mixed
script" and that several groups who are concerned about
user-level spoofing and phishing consider mixed script labels to
be immediately suspicious.

Just for planning: due to other commitments, I'm unlikely to be
able to follow this list carefully or respond to messages
quickly during the rest of this week, so, if I don't respond to
what might otherwise be a conversation, please do not assume
agreement.

Also, since your name is relatively new to me and mine may be
new to you, it might save time to tell you that I'm the author
or co-author of RFC 5321, 5890, 5891, 5894, and that I was
co-chair of the "EAI" working group and am co-author of a few of
its documents as well.   I've been immersed in this stuff for a
rather long time and, while that doesn't make my views correct,
it, and the things that led to it, do imply a certain amount of
experience and perspective.

best,
    john

>> into an ugly mess and invitation to assorted attacks,
>> especially if that script either looks a lot like Latin or is
>> mostly written right to left.   Naming conventions have their
>> place and can be really convenient, but turning them into
>> protocol elements rather than hints for convenience is just a
>> really bad idea.
>>

---

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

Hello Mr. Klensin,

Thanks for the input.

You are right. I'm new here. This is my first RFC proposal. If you think my
solution gonna cause problems, then I have no problem if you reject my
proposal.

-- 
Best Regards,

---

From: John C Klensin <[email-masked]>
Date: Mon, 07 Jan 2019 11:49:32 -0500

--On Monday, January 7, 2019 21:49 +0530 Viruthagiri
Thirumavalavan <[email-masked]> wrote:

> Hello Mr. Klensin,
> 
> Thanks for the input.
> 
> You are right. I'm new here. This is my first RFC proposal. If
> you think my solution gonna cause problems, then I have no
> problem if you reject my proposal.

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.

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.
    john

---

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

Thanks Mr. Klensin,

I'll get started right away.

-- 
Best Regards,

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 8 Jan 2019 13:08:04 +0100

I like Viruthagiri's proposal.

> effective communication than one might like, before going down

Well, yes, tweaking host names in MX record would have been a nice hack.  As it
seems such a hack won't work well, however, it's better to save the camel a
useless burden altogether.  Perhaps, the probability of finding an smtps
service on port 26 can be advertised by some other means.

As for port 26, nmap reports[*] a seldom used, unofficial "rsftp" there:

# Fields : Service name, portnum/protocol, open-frequency, optional comments
#
# [...]

telnet	23/tcp	0.221265
telnet	23/udp	0.006211
priv-mail	24/tcp	0.001154	# any private mail system
priv-mail	24/udp	0.000329	# any private mail system
smtp	25/tcp	0.131314	# Simple Mail Transfer
smtp	25/udp	0.001285	# Simple Mail Transfer
rsftp	26/tcp	0.007991	# RSFTP

Would 24 be better?

Rsftp seems to be a buggy ftp-like program.[†]  Google didn't help me to find
much more.  There are some projects on github called rsftp[‡], but none of them
is that one.

Best
Ale

-- 
[*] https://svn.nmap.org/nmap/nmap-services
[†] http://codegrazer.com/blog/rsftp-to-command-injection.html
[‡] https://github.com/tuzhao/rsftp
    https://github.com/cyroxx/rsftp
    https://github.com/Sage-Bionetworks/Rsftp
    https://github.com/rsWinAutomationSupport/rsFTPAdministration (related)

---

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

If rsftp gonna cause issue then yes we can go for another port.

Would 24 be better?

In my opinion the port number should be greater than port 25 to denote it's
the "superior" version of port 25.  Maybe I'm being silly here :-)

-- 
Best Regards,

---

From: Richard Clayton <[email-masked]>
Date: Tue, 8 Jan 2019 13:08:21 +0000

In message <[email-masked]>, Paul Smith
<[email-masked]> writes

>downgrade for any sender willing to support it.

doesn't RFC 8461 provide what you wish for ?

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

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

@Gilles Chehade

I think Paul Smith already clarified that part. So yes we have SMTPS right
now only for submission. Not for the relay. That's what this proposal is
all about.

ISPs usually block port 25 to prevent outgoing email spam (direct-to-mx).
That's one of the reasons why we introduced port 587 for submission (e.g.
iPhone mail app to gmail). Port 465 is the secure version of port 587. If
we use the port 465 as secure alternative to port 25, then we are
introducing the same (direct-to-mx) problem again. So we need a new
unallocated port.

Three days back when I prepared my proposal for uta working group, it had
all that port history information. To simplify the document, I removed
<https://gist.github.com/mistergiri/a4c9a5f1c26fd7003ebc0652af95d314/revisions>
the smtp history related content.

I just created a new github gist and added back that content.
https://gist.github.com/mistergiri/16314f21077d1f0aaa6e3a66ee0fabe2

Hope someone find that useful. Let me know if I'm wrong somewhere or missed
something.

Thanks

On Tue, Jan 8, 2019 at 6:39 PM Richard Clayton <[email-masked]>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGPsdk version 1.7.1
>
> iQA/AwUBXDSgxTu8z1Kouez7EQKcZgCg4KASq4mxUC9fjFMpFtkpcpc4e60AnjnX
> msVphIabOk6qCw/82FSxstUt
> =sHmk
> -----END PGP SIGNATURE-----
>

-- 
Best Regards,

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Tue, 8 Jan 2019 22:07:49 +0530

@Gilles Chehade

> feel you're hacking behavior by encoding it in a field that's not meant

Could you clarify that part? What do you mean by opportunistic smtps? Why
do we need that?

smtps protects everything from top to bottom like https. In opportunistic
encryption, the conversation get started as plain text and gets upgraded to
a secure connection when the sever presents an opportunity.

Why do you wanna combine both?

On Tue, Jan 8, 2019 at 9:35 PM Viruthagiri Thirumavalavan <[email-masked]>
wrote:

> Hope someone find that useful. Let me know if I'm wrong somewhere or
> missed something.
>
> Thanks
>

-- 
Best Regards,

---

From: [email-masked]
Date: Tue, 08 Jan 2019 12:23:16 -0500

> Why do you wanna combine both?

It would be a useful exercise to go through and enumerate the exact difference
between the protection provided by smtps that starttls doesn't provide.

Hint: If starttls is subject to a downgrade attack, what prevents the same attack
against the same pair of hosts attempting smtps instead?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Jan 2019 13:43:25 -0500

> against the same pair of hosts attempting smtps instead?

IOW, if the server is only listening on port 26, and the client is being MITM'd, the attacker can listen on port 25 and then tunnel the client connection to the server's port 26.  Only if the client knows that the server supports TLS can you prevent a downgrade, and then STARTTLS works fine.   So you need some secure way of signaling this, e.g. DNSSEC, and if you have that, then you don't need a second port allocation.

---

From: Paul Smith <[email-masked]>
Date: Tue, 08 Jan 2019 19:32:52 +0000

This was my point. I'm not sure what SMTPS gains us over protection against 
STARTTLS downgrade, so protect against STARTTLS downgrade by all means, but 
the alternative port is a red herring and unnecessary complexity (IMHO)
On 8 January 2019 18:44:01 Ted Lemon <[email-masked]> wrote:
> IOW, if the server is only listening on port 26, and the client is being 
> MITM'd, the attacker can listen on port 25 and then tunnel the client 
> connection to the server's port 26.  Only if the client knows that the 
> server supports TLS can you prevent a downgrade, and then STARTTLS works 
> fine.   So you need some secure way of signaling this, e.g. DNSSEC, and if 
> you have that, then you don't need a second port allocation.
>

--

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Jan 2019 16:55:15 -0500

Sure, although a simple TXT record doesn't really seem like a useful
answer, particularly without DNSSEC.  Regarding your point about SRV, have
you seen RFC 7673, Using DANE TLSA Records with SRV Records?

On Tue, Jan 8, 2019 at 2:38 PM Paul Smith <[email-masked]> wrote:

>
> This was my point. I'm not sure what SMTPS gains us over protection
> against STARTTLS downgrade, so protect against STARTTLS downgrade by all
> means, but the alternative port is a red herring and unnecessary complexity
> (IMHO)
>
> Sign up for news & updates <http://http://www.pscs.co.uk/go/subscribe>
>

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Wed, 9 Jan 2019 04:54:50 +0530

@Paul Smith

> the alternative port is a red herring and unnecessary complexity (IMHO)

We need alternative port to provide Implicit TLS. To do that, first we all
need to be convinced with the fact "Implicit TLS > Opportunistic TLS".

Today, we all can safely browse NSFW sites via browser because HTTPS
protects everything from top to bottom. My SMTPS proposal can do the same
job for email.

To be clear, this is the problem with Opportunistic TLS.

A guy who sends an email to AshleyMadison support team probably cheating
his wife. He can protect the real conversation by upgrading the connection
to a secure connection with the help of STARTTLS. But the handshake before
the upgrade goes like this in plain text.

220 mail.ashleymadison.com AshleyMadison ESMTP Service Ready

That one line says plenty enough about this guy. You don't have to read the
real conversation to figure out what's going on here.

AshleyMadison is the best example I can give. But there might be more
serious privacy issues too. So, in my opinion, Implicit TLS is better than
Opportunistic TLS.

Like I mentioned earlier, I have no issues if the proposal gets turned
down. But you guys need to convince me with why you all think
"Opportunistic TLS" is enough for SMTP.

-- 
Best Regards,

---

From: [email-masked]
Date: Tue, 08 Jan 2019 18:28:41 -0500

On Tue, 08 Jan 2019 13:43:25 -0500, Ted Lemon said:

> IOW, if the server is only listening on port 26, 

Which becomes a self-inflicted DoS unless and until a vast majority of SMTP
sending servers have been upgraded/configured to try port 26.

https://www.rhyolite.com/anti-spam/you-might-be.html#senior-IETF-member-5
The FUSSP won't be effective until it has been deployed at more than 60% of
SMTP servers and that's not a problem.

I'm pretty sure that Vernon Schryver wrote that last century.  That puts it
well into "Wisdom of the Ancients" territory.. :)

> and the client is being MITM'd, the attacker can listen on port 25 and then
> tunnel the client connection to the server's port 26

I'll point out that if somebody is sufficiently MITM to do the "tunnel 26 to
25" tap-dance , they're sufficiently MITM to forge RST packets to attempted
connections on port 26 and force a client to fall back to port 25.

And nobody sane will deploy a system that doesn't fall back to port 25.

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Wed, 9 Jan 2019 05:03:28 +0530

>
> If starttls is subject to a downgrade attack, what prevents the same attack

A snippet from my proposal.

Whoever opt for "SMTPS (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.

-- 
Best Regards,

---

From: Mark Andrews <[email-masked]>
Date: Wed, 9 Jan 2019 11:08:15 +1100

> On 7 Jan 2019, at 7:25 pm, Viruthagiri Thirumavalavan <[email-masked]> wrote:
> 
> Hello Everyone,
> 
> I have proposal for SMTPS. Already gathered some feedback from UTA working group and improved my draft.
> 
> My proposal is a very simple document. So, please go though it and give me feedback if you can.  
> 
> Here is my abstract.
> 
> ---------
> SMTP is still suffering from downgrade attacks like STRIPTLS. While we have "Opportunistic TLS", we still don't have "Implicit TLS" in the SMTP. Don't get me wrong.. We do have "Implicit TLS" for "SMTP Submission" on port 465. But we don't have a secure port 25 alternative. i.e. The real SMTPS
> 
> 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.

Are you saying that generating a TLSA records is hard?  There are plenty of tools available for that.

e.g. https://www.huque.com/bin/gen_tlsa

Are you saying DNSSEC is hard?  Really?  Have you tried to publish a signed zone lately?

Create 2 keys one of which has the KSK flag set.

dnssec-keygen -A RSASHA256 -b 4096 -K /var/named/keys -f KSK example.net
dnssec-keygen -A RSASHA256 -b 4096 -K /var/named/keys example.net

and in named.conf you tell named to where to find the keys and to sign the zone maintaining the RRSIG records.  With a 4096 bit RSA key you really don’t need to roll the DNSKEYs ever.

options {
	key-directory "/var/named/keys”;
};

zone example.net {
	type master;
	file “/var/named/master/example.net.db”;
	auto-dnssec maintain;
	inline-signing yes;
};

Once that is setup you add DS records to the parent zone which is no harder than adding NS records.

It’s the same or simpler level of complexity with other name server implementations.

Add to that most (>50%) of the DNS responses on the planet are being DNSSEC validated today even if the result of that validation is insecure, there is no way to say DNSSEC should be seen as a reason
to invent a new method.

Sorry, "DNSSEC is HARD" is a MYTH.  DNSSEC isn’t deployed is a MYTH.  It’s come a long way from having to manually re-sign the zone with external tools periodically.  Just because your favourite registrar or DNS hosting service has been asleep at the wheel for a decade doesn’t make it hard, it just means you need to switch to someone that wants your business and implements todays DNS and not that of the 1980’s.

And name servers can even return most the records the MTA needs in a single query.

[beetle:bin/tests/system] marka% dig mx isc.org +dnssec
;; BADCOOKIE, retrying.

; <<>> DiG 9.13.1+hotspot+add-prefetch+marka <<>> mx isc.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10869
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 13

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 0cc82edbe25fb743b37327535c35380e644e065163baae04 (good)
;; QUESTION SECTION:
;isc.org.			IN	MX

;; ANSWER SECTION:
isc.org.		6793	IN	MX	10 mx.pao1.isc.org.
isc.org.		6793	IN	MX	20 mx.ams1.isc.org.
isc.org.		6793	IN	RRSIG	MX 5 2 7200 20190206233314 20190107233314 19923 isc.org. UBu26XwokUyCwZvBzp5+kajy686RF4cdA/Un3Z3vtEARG8qx0hQfHoTk lGfGPkt21QdZmqX+ZJcdO3LfA+qU9A3aEJMXZi9aMZkPDWu1aPsJBu6U 3U3Tj9j+DsqL2Uk780TAqQQQWFUwIHF+y0hcRIWPaqUuvygl/5jxdVDN Mls=

;; ADDITIONAL SECTION:
mx.pao1.isc.org.	3195	IN	A	149.20.64.53
mx.ams1.isc.org.	3199	IN	A	199.6.1.65
mx.pao1.isc.org.	3195	IN	AAAA	2001:4f8:0:2::2b
mx.ams1.isc.org.	3200	IN	AAAA	2001:500:60::65
mx.pao1.isc.org.	3195	IN	RRSIG	A 5 4 3600 20190206233333 20190107233333 13902 pao1.isc.org. WrDcCGC0SmNUSh+DBxogVXWU2PQVpJ/6S/WJxpU4fLDpI+0J85aep+e1 NwZRUuw9N5RRuslQSz0y+aiwB0RACq2wbPUxDem21KpzKE8rlrAlf0U9 k9sT1PeCkWu7QOiWgEksnoJijyCVY41Q/GB0HnWzaO4jUtay6e/PBj4c IiA=
mx.pao1.isc.org.	3195	IN	RRSIG	AAAA 5 4 3600 20190206233333 20190107233333 13902 pao1.isc.org. EaYgxAGrmJ9oiX4u2DfIcHKCqen3RNGylmWT0VjJ8VWY5e/c5TA1eI5U evGsvYhvLD4WvR8hzvKxp4Pc5EYKLoB+YRI4ttUgnTydsEI0xFCcgB4+ dFb+89h8e6tHSPhUa1wa7ObriKm1O5FzplEXLfNFbgEUN6oJOIMw7q8w cC8=
_25._tcp.mx.pao1.isc.org. 3197	IN	RRSIG	TLSA 5 6 3600 20190206233333 20190107233333 13902 pao1.isc.org. liSDcLgGpDXqgTxkv2sQBI3OsACPflpxoZxcrgSge4yTe5gA97NOPe0l ECmDBPzUkhcRI6Mwv+uBCmm5FBvgh0leNxLXzACdkCX8EscE3v74wd5o ReCRGFAhV6TBjycwejkGARVTYF23RyRflq2/fRV2hoOdH2ImcW7/SMqA 8Jg=
mx.ams1.isc.org.	3199	IN	RRSIG	A 5 4 3600 20190206233315 20190107233315 5730 ams1.isc.org. E+6nzEbFAcftlr3UTaCcw0LAHYIdVe5TNfyIwVwU71AzZB22jiif/BrQ KxemOrR7LT7ukfDRjnEzfV1/s0Wwfxh0b79otxrDwssKzNKz9XhaIhVf j17oyuQBkYjYv5RBuwsrmKQmSbu56Zu7G35xp2qbKi6E+3lpXPghnrnJ DBk=
mx.ams1.isc.org.	3200	IN	RRSIG	AAAA 5 4 3600 20190206233315 20190107233315 5730 ams1.isc.org. ov/6HUTx8v7t31KBYVgDy02Bpe8rJX431vPDdRZvKKhffFrYmUOIXEqD Q/3+DNV1axSJCTONJ1NwzoSC8LDwQQFUcAsXnhcW/C/Z3rbaEthetmmP TERuRGjF3QdA+qFM8RCc83s+hp1RXo5cU+9wA8OTPT5nTmfthkDs/cUi 0o8=
_25._tcp.mx.ams1.isc.org. 3202	IN	RRSIG	TLSA 5 6 3600 20190206233315 20190107233315 5730 ams1.isc.org. qdzOyIbkPhufqw6/B5bwpxJ0pfVeUay2v8O5spUa+xgHdLQFNS851vlW KOYrNfZALDomXkOyfAVTEZXQ1g3xf0gzIcRCy0PHcgDtgl5a56AilFGB n6LZVkh6lbAkQ8lSmlKWmOvAmJnXh6L6dX8/CQzpWT7G0EEL1EcvLW6p uZ0=
_25._tcp.mx.pao1.isc.org. 3197	IN	TLSA	3 0 1 71903FF43D60CA91BDB7AA0DFE9C247B1A2C5A6002C436451C3C1684 0C607AE0
_25._tcp.mx.ams1.isc.org. 3202	IN	TLSA	3 0 1 5EF9B10DA21B2711522982EAD699FBABE77FD07FF07AC810608A85DA 66AFE916

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jan 09 10:53:50 AEDT 2019
;; MSG SIZE  rcvd: 1555

[beetle:bin/tests/system] marka% 

This draft is not needed.  ALL IT DOES IS MAKE MORE WORK MTA IMPLEMENTERS AND OPERATORS.

DO NOT PROCEED!!!!!!!!!!!!!!

> This document propose a new port 26, an "Implicit TLS" alternative for port 25 and recommends the MX server to signal the port via a prefix.
> 
> Where "smtps-" 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".
> --------
> 
> Thanks
> 
> -- 
> Best Regards,
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Jan 2019 19:29:20 -0500

> 220 mail.ashleymadison.com AshleyMadison ESMTP Service Ready

Ah, right, I misunderstood your use case.   However, who is it who needs
privacy here?   The end user is never going to connect to ashleymadison.com
.

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Wed, 9 Jan 2019 06:00:16 +0530

@Mark Andrews

First, When I mentioned "The former requires a HTTPS server and the latter
requires DNSSEC.", I didn't mean DNSSEC is HARD to implement. I meant
DNSSEC is CONTROVERSIAL

Read some of these articles.

https://sockpuppet.org/blog/2015/01/15/against-dnssec/
https://www.theregister.co.uk/2016/02/23/dnssec_more_problem_than_solution/

Second, unless top domains like Google, Facebook etc. start to use DNSSEC,
you are gonna see questions like this.

https://security.stackexchange.com/questions/21121/if-dnssec-is-so-useful-why-is-its-deployment-non-existent-for-top-domains

So if you wanna convince others to use DNSSEC, you should start with big
brothers like Google.

Third, Yes DNSSEC is HARD. Maybe not for you. [You seem like a person who
knows your stuff]

We are talking about mail servers here. Many of these users are non-tech
savvy users who depends on third-party mail hosting services like G-Suite.

As an engineer you can do those stuffs easily. But a doctor can't do that.
Just because he can't configure DNSSEC doesn't mean he don't deserve
security

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Wed, 9 Jan 2019 06:13:04 +0530

There are people out there who has personal websites like
firstnamelastname.com and email address like [email-masked]

They are the only users of that domain and they probably need privacy. i.e.
If someone log the outgoing mails of firstnamelastname.com, then the
privacy is being breached here. So those users don't want any traces.
Implicit TLS offers that.

On Wed, Jan 9, 2019 at 5:59 AM Ted Lemon <[email-masked]> wrote:

> privacy here?   The end user is never going to connect to
> ashleymadison.com.
>

-- 
Best Regards,

---

From: [email-masked]
Date: Tue, 08 Jan 2019 19:55:12 -0500

> Implicit TLS offers that.

So explain what your proposal gives us that DNSSEC+STARTTLS doesn't give us?

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Wed, 9 Jan 2019 06:31:19 +0530

> So explain what your proposal gives us that DNSSEC+STARTTLS doesn't give

*mail.example.com <http://mail.example.com> connecting to mail.yahoo.com
<http://mail.yahoo.com> with its IP address*
*yahoo.com <http://yahoo.com> => 220 mail.yahoo.com <http://mail.yahoo.com>
Yahoo ESMTP Service Ready*
*example.com <http://example.com> => EHLO mail.example.com
<http://mail.example.com>*
*yahoo.com <http://yahoo.com> => 250-Hello, nice to meet you,
mail.example.com <http://mail.example.com>*
*yahoo.com <http://yahoo.com> => 250-SIZE 1000000*
*yahoo.com <http://yahoo.com> => 250-8BITMIME*
*yahoo.com <http://yahoo.com> => 250 STARTTLS*
*example.com <http://example.com> => STARTTLS*
*yahoo.com <http://yahoo.com> => 220 Go ahead*
*Key exchange happens here and the rest of the email part is encrypted *

Are you saying all of those parts can be encrypted via DNSSEC+STARTTLS?

-- 
Best Regards,

---

From: [email-masked]
Date: Tue, 08 Jan 2019 20:14:16 -0500

> Are you saying all of those parts can be encrypted via DNSSEC+STARTTLS?

What's in there that we didn't already know after the 3-packet handshake?

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Wed, 9 Jan 2019 06:54:16 +0530

I just gave a pretty good example on why SMTPS better than STARTTLS.

I'm not sure what else you are expecting from me.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 9 Jan 2019 12:32:09 +1100

> On 9 Jan 2019, at 11:30 am, Viruthagiri Thirumavalavan <[email-masked]> wrote:
> 
> @Mark Andrews
> 
> First, When I mentioned "The former requires a HTTPS server and the latter requires DNSSEC.", I didn't mean DNSSEC is HARD to implement. I meant DNSSEC is CONTROVERSIAL
> 

A whole heap of half truths and poor analysis.  If that was presented as a peer reviewed article it would not be published.  You have been had if you believe that blog post.

> https://www.theregister.co.uk/2016/02/23/dnssec_more_problem_than_solution/

“Oh Dear, Big Responses, The World is Going To End!!!!!”.  This is click bait journalism.  We have standard track RFCs which provide the equivalent of TCP’s three way handshake for DNS/UDP.  This has been deployed for 4+ years now along with other measures for clients that don’t implement the RFC.  8% of the TLD servers currently implement that RFC.  It is on by default in all current implementations of BIND (both client and server side) and with the exception of a handful of (non RFC compliant) servers it causes no issues.

> Second, unless top domains like Google, Facebook etc. start to use DNSSEC, you are gonna see questions like this.
> 

28171 of 895949 zones which gave good answers from the alexa to 1M are signed based on the run I started 2018-12-23T00:00:05Z.  The EDNS compliance testing I do also reports whether the returned result is signed (ok,yes) or not (ok).

% awk '$13 ~ /signed=ok,yes/ {yes[$1] = 1} $13 ~ /signed=ok/ { ok[$1] = 1} END { print length ( yes ) , length ( ok ) } ' reports/alexa1m.2018-12-23T00:00:05Z
28171 895949
%

> So if you wanna convince others to use DNSSEC, you should start with big brothers like Google. 
> 
> Third, Yes DNSSEC is HARD. Maybe not for you. [You seem like a person who knows your stuff]

No it isn’t.  In Unbound it is a checkbox where the server generates the DNSKEYs and choosing the algorithm.  Are you saying ticking a checkbox is HARD?  There TLD’s with +70% of the delegated zones signed.  You don’t get to that level with “DNSSEC is HARD”.  The only reason DNSSEC is not deployed more is COMPLACENCY and FEAR OF SOMETHING NEW.

Neither if these reasons == HARD.

> We are talking about mail servers here. Many of these users are non-tech savvy users who depends on third-party mail hosting services like G-Suite.

Which almost certainly are using STARTTLS today and maybe using DANE today as well on the outbound side.

> As an engineer you can do those stuffs easily. But a doctor can't do that. Just because he can't configure DNSSEC doesn't mean he don't deserve security 

And he can get DNSSEC today.  There are DNS hosting providers that will do DNSSEC.  Almost all the
TLDs support DNSSEC.  There are DNS hosting providers that turn DNSSEC ON BY DEFAULT.  Arguing that you can’t deploy a DNSSEC signed zone today even as a lay person doesn’t bear up to scrutiny.

Mark

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Wed, 9 Jan 2019 07:12:15 +0530

You just invalidated all my arguments even though I provided sources.

So let me try in a different way.

If you think DNSSEC is so simple and not controversial, why do we need
MTA-STS?

On Wed, Jan 9, 2019, 7:02 AM Mark Andrews <[email-masked] wrote:

> > First, When I mentioned "The former requires a HTTPS server and the
> latter requires DNSSEC.", I didn't mean DNSSEC is HARD to implement. I
> meant DNSSEC is CONTROVERSIAL
> >
> A whole heap of half truths and poor analysis.  If that was presented as a
> peer reviewed article it would not be published.  You have been had if you
> believe that blog post.
>
> >
> “Oh Dear, Big Responses, The World is Going To End!!!!!”.  This is click
> bait journalism.  We have standard track RFCs which provide the equivalent
> of TCP’s three way handshake for DNS/UDP.  This has been deployed for 4+
> years now along with other measures for clients that don’t implement the
> RFC.  8% of the TLD servers currently implement that RFC.  It is on by
> default in all current implementations of BIND (both client and server
> side) and with the exception of a handful of (non RFC compliant) servers it
> causes no issues.
>
> > Second, unless top domains like Google, Facebook etc. start to use
> DNSSEC, you are gonna see questions like this.
> >
> >
> 28171 of 895949 zones which gave good answers from the alexa to 1M are
> signed based on the run I started 2018-12-23T00:00:05Z.  The EDNS
> compliance testing I do also reports whether the returned result is signed
> (ok,yes) or not (ok).
>
> % awk '$13 ~ /signed=ok,yes/ {yes[$1] = 1} $13 ~ /signed=ok/ { ok[$1] = 1}
> END { print length ( yes ) , length ( ok ) } '
> reports/alexa1m.2018-12-23T00:00:05Z
> 28171 895949
> %
>
> No it isn’t.  In Unbound it is a checkbox where the server generates the
> DNSKEYs and choosing the algorithm.  Are you saying ticking a checkbox is
> HARD?  There TLD’s with +70% of the delegated zones signed.  You don’t get
> to that level with “DNSSEC is HARD”.  The only reason DNSSEC is not
> deployed more is COMPLACENCY and FEAR OF SOMETHING NEW.
>
> > As an engineer you can do those stuffs easily. But a doctor can't do
> that. Just because he can't configure DNSSEC doesn't mean he don't deserve
> security
>
> TLDs support DNSSEC.  There are DNS hosting providers that turn DNSSEC ON
> BY DEFAULT.  Arguing that you can’t deploy a DNSSEC signed zone today even
> as a lay person doesn’t bear up to scrutiny.
>
> Mark
> --
> Mark Andrews, ISC

---

From: [email-masked]
Date: Tue, 08 Jan 2019 20:51:40 -0500

> I just gave a pretty good example on why SMTPS better than STARTTLS.

Oh? In what way is it "pretty good"?  Yes, SMTPS would hide the initial 220
message, the EHLO and the response - but there's no info in those two that
aren't already known after the 3-packet handshake and a few DNS PTR queries
or obtained by other means - you're going to have  a really hard time claiming
that things like 8bitmime being advertised in the EHLO reply constitute
sensitive info.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 9 Jan 2019 12:57:09 +1100

> On 9 Jan 2019, at 12:42 pm, Viruthagiri Thirumavalavan <[email-masked]> wrote:
> 
> If you think DNSSEC is so simple and not controversial, why do we need MTA-STS?

The simple answer is WE DO NOT *NEED* MTA-STS.  Additionally it can be spoofed
without DNSSEC.  The only thing it does is reduce the number of players involved
if you are not self hosting.

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Wed, 9 Jan 2019 07:38:14 +0530

> that things like 8bitmime being advertised in the EHLO reply constitute

Not every PTR queries resolves to the correct domain.

74.125.129.26 => jm-in-f26.1e100.net (A google IP address, but point to a
different domain owned by google)

I would be ok with indirectly someone getting the info rather than directly
providing it.

On Wed, Jan 9, 2019 at 7:27 AM Mark Andrews <[email-masked]> wrote:

> > A whole heap of half truths and poor analysis.  If that was presented as
> a peer reviewed article it would not be published.  You have been had if
> you believe that blog post.
> >
> > >
> > % awk '$13 ~ /signed=ok,yes/ {yes[$1] = 1} $13 ~ /signed=ok/ { ok[$1] =
> 1} END { print length ( yes ) , length ( ok ) } '
> > > We are talking about mail servers here. Many of these users are
> non-tech savvy users who depends on third-party mail hosting services like
> G-Suite.
> >
> > TLDs support DNSSEC.  There are DNS hosting providers that turn DNSSEC
> ON BY DEFAULT.  Arguing that you can’t deploy a DNSSEC signed zone today
> even as a lay person doesn’t bear up to scrutiny.
> >
> > Mark
> > --
> > Mark Andrews, ISC

-- 
Best Regards,

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Wed, 9 Jan 2019 07:49:11 +0530

> if you are not self hosting.

I get it. You are a fan of DNSSEC. But you should know that I'm not against
DNSSEC (or even STS for that matter). If you think like that, then you have
not read my proposal.

My proposal introduces SMTPS for better security and signal the port via a
prefix. But authentication steps should be given to either DNSSEC or STS.

Also note, my proposal only trying to INTRODUCE the SMTPS via port 26. It
doesn't force anyone to use SMTPS.

If you use the prefix in your mx host like smtps-mx1.example.com, you are
saying that your server supports both port 26 and 25. Clients should drop
the connection if the certificate is invalid in either port.

If you use the prefix in your mx host like starttls-mx1.example.com, you
are saying that your server supports only port 25. Clients should drop the
connection if the STARTTLS command not found in the EHLO response or valid
certificate not found.

On Wed, Jan 9, 2019 at 7:38 AM Viruthagiri Thirumavalavan <[email-masked]>
wrote:

> I would be ok with indirectly someone getting the info rather than
> directly providing it.
>
>
>> > A whole heap of half truths and poor analysis.  If that was presented
>> as a peer reviewed article it would not be published.  You have been had if
>> > “Oh Dear, Big Responses, The World is Going To End!!!!!”.  This is
>> click bait journalism.  We have standard track RFCs which provide the
>> equivalent of TCP’s three way handshake for DNS/UDP.  This has been
>> deployed for 4+ years now along with other measures for clients that don’t
>> implement the RFC.  8% of the TLD servers currently implement that RFC.  It
>> is on by default in all current implementations of BIND (both client and
>> server side) and with the exception of a handful of (non RFC compliant)
>> servers it causes no issues.
>> >
>> > No it isn’t.  In Unbound it is a checkbox where the server generates
>> the DNSKEYs and choosing the algorithm.  Are you saying ticking a checkbox
>> is HARD?  There TLD’s with +70% of the delegated zones signed.  You don’t
>> get to that level with “DNSSEC is HARD”.  The only reason DNSSEC is not

-- 
Best Regards,

---

From: Mark Andrews <[email-masked]>
Date: Wed, 9 Jan 2019 13:26:37 +1100

> On 9 Jan 2019, at 1:19 pm, Viruthagiri Thirumavalavan <[email-masked]> wrote:
> 
> I get it. You are a fan of DNSSEC. But you should know that I'm not against DNSSEC (or even STS for that matter). If you think like that, then you have not read my proposal. 
> 
> My proposal introduces SMTPS for better security and signal the port via a prefix. But authentication steps should be given to either DNSSEC or STS.
> 
> Also note, my proposal only trying to INTRODUCE the SMTPS via port 26. It doesn't force anyone to use SMTPS.
> 
> If you use the prefix in your mx host like smtps-mx1.example.com, you are saying that your server supports both port 26 and 25. Clients should drop the connection if the certificate is invalid in either port.

Which will be defeated by a MiTM attack unless DNSSEC is used.  Strip the “smtps-“ prefixes from the responses and dummy up non “smtps-" records.

> If you use the prefix in your mx host like starttls-mx1.example.com, you are saying that your server supports only port 25. Clients should drop the connection if the STARTTLS command not found in the EHLO response or valid certificate not found.

Again it can be defeated by a MiTM attack.  Same method.

> On Wed, Jan 9, 2019 at 7:38 AM Viruthagiri Thirumavalavan <giri@dombox..org> wrote:
> 74.125.129.26 => jm-in-f26.1e100.net (A google IP address, but point to a different domain owned by google)
> 
> I would be ok with indirectly someone getting the info rather than directly providing it.  
> 
>

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Wed, 9 Jan 2019 08:04:50 +0530

Why do you think all MiTM attacker will have control over DNS?

If that's the case, then we have been fooled by STARTTLS saying it's secure
for the past 20 years.

On Wed, Jan 9, 2019, 7:56 AM Mark Andrews <[email-masked] wrote:

> > I get it. You are a fan of DNSSEC. But you should know that I'm not
> against DNSSEC (or even STS for that matter). If you think like that, then
> you have not read my proposal.
> >
> > My proposal introduces SMTPS for better security and signal the port via
> a prefix. But authentication steps should be given to either DNSSEC or STS.
> >
> > If you use the prefix in your mx host like smtps-mx1.example.com, you
> are saying that your server supports both port 26 and 25. Clients should
> drop the connection if the certificate is invalid in either port.
>
> Which will be defeated by a MiTM attack unless DNSSEC is used.  Strip the
> “smtps-“ prefixes from the responses and dummy up non “smtps-" records.
>
> > If you use the prefix in your mx host like starttls-mx1.example.com,
> you are saying that your server supports only port 25. Clients should drop
> the connection if the STARTTLS command not found in the EHLO response or
> valid certificate not found.
>
> > > % awk '$13 ~ /signed=ok,yes/ {yes[$1] = 1} $13 ~ /signed=ok/ { ok[$1]
> = 1} END { print length ( yes ) , length ( ok ) } '

---

From: [email-masked]
Date: Tue, 08 Jan 2019 21:38:16 -0500

> I would be ok with indirectly someone getting the info rather than directly

The point is that when it's *that* easy to get the information indirectly, you're
not providing actual security, you're providing security theater.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 9 Jan 2019 13:45:40 +1100

> On 9 Jan 2019, at 1:34 pm, Viruthagiri Thirumavalavan <[email-masked]> wrote:
> 

Because they ARE IN THE MIDDLE.  You can modify DNS responses as easily as SMTP streams.  Firewall vendors that strip STARTTLS will just modify the DNS responses if this draft gets published.

> If that's the case, then we have been fooled by STARTTLS saying it's secure for the past 20 years. 

Why do you think DANE requires signed and validated as secure DNSSEC responses to the MX/SRV/AAAA/A lookups before it even attempts
a TLSA lookup?  You need to know that the inputs have not been spoofed before deciding if you can trust a CERT being presented.

If your SMTP service provider does not support DANE they DO NOT REALLY CARE ABOUT SECURITY.

Mark

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Wed, 9 Jan 2019 08:24:06 +0530

>
> Why do you think DANE requires signed and validated as secure DNSSEC
> responses to the MX/SRV/AAAA/A lookups before it even attempts
> a TLSA lookup?  You need to know that the inputs have not been spoofed
> before deciding if you can trust a CERT being presented.

You definitely need to take a look at my proposal's 2FA section. I'm
recommending both STS and DANE. Again I'm not against them.

https://gist.github.com/mistergiri/a4c9a5f1c26fd7003ebc0652af95d314#2fa

This proposal is about two things.

1) SMTPS via 26
2) Signal via Prefix

So you can go easy on me with those DANE/DNSSEC discussion.

On Wed, Jan 9, 2019 at 8:15 AM Mark Andrews <[email-masked]> wrote:

> Because they ARE IN THE MIDDLE.  You can modify DNS responses as easily as
> SMTP streams.  Firewall vendors that strip STARTTLS will just modify the
> DNS responses if this draft gets published.
>
> Why do you think DANE requires signed and validated as secure DNSSEC
> responses to the MX/SRV/AAAA/A lookups before it even attempts
> a TLSA lookup?  You need to know that the inputs have not been spoofed
> before deciding if you can trust a CERT being presented.
>
> > > My proposal introduces SMTPS for better security and signal the port
> via a prefix. But authentication steps should be given to either DNSSEC or
> STS.
> > >
> > Which will be defeated by a MiTM attack unless DNSSEC is used.  Strip
> the “smtps-“ prefixes from the responses and dummy up non “smtps-" records.
> >
> > > > > First, When I mentioned "The former requires a HTTPS server and
> the latter requires DNSSEC.", I didn't mean DNSSEC is HARD to implement. I
> > > > A whole heap of half truths and poor analysis.  If that was
> presented as a peer reviewed article it would not be published.  You have
> been had if you believe that blog post.
> > > >
> > > > >
> > > > 28171 of 895949 zones which gave good answers from the alexa to 1M
> are signed based on the run I started 2018-12-23T00:00:05Z.  The EDNS
> > > > % awk '$13 ~ /signed=ok,yes/ {yes[$1] = 1} $13 ~ /signed=ok/ {
> ok[$1] = 1} END { print length ( yes ) , length ( ok ) } '
> > > > > As an engineer you can do those stuffs easily. But a doctor can't
> do that. Just because he can't configure DNSSEC doesn't mean he don't
> deserve security
> > > >
> > > > TLDs support DNSSEC.  There are DNS hosting providers that turn
> DNSSEC ON BY DEFAULT.  Arguing that you can’t deploy a DNSSEC signed zone
> today even as a lay person doesn’t bear up to scrutiny.
> > > >
> > > > Mark
> > > > --
> > > > Mark Andrews, ISC

-- 
Best Regards,

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Wed, 9 Jan 2019 08:29:03 +0530

> not providing actual security, you're providing security theater.

It's not *that* easy. And that's my whole point. There are ptr records that
points to in-addr.arpa rather than real domain.
But if you believe this proposal is pointless, then I'll take your vote as
"No" for this proposal.

Thanks

On Wed, Jan 9, 2019 at 8:08 AM <[email-masked]> wrote:

> directly

-- 
Best Regards,

---

From: Mark Andrews <[email-masked]>
Date: Wed, 9 Jan 2019 14:03:35 +1100

> On 9 Jan 2019, at 1:59 pm, Viruthagiri Thirumavalavan <[email-masked]> wrote:
> 
> It's not *that* easy. And that's my whole point. There are ptr records that points to in-addr.arpa rather than real domain. 
> But if you believe this proposal is pointless, then I'll take your vote as "No" for this proposal.

So the snooper just makes a connection over port 26 to the server to fill in the missing
information if they want it.

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Wed, 9 Jan 2019 08:41:55 +0530

> information if they want it.

Ok I missed that one. Good point.

I'm not sure whether all snoopers would know all these loopholes.

You already mentioned "No" to this proposal. If anything else following
this thread, please let me know where you stand.

Thanks

On Wed, Jan 9, 2019 at 8:33 AM Mark Andrews <[email-masked]> wrote:

> > It's not *that* easy. And that's my whole point. There are ptr records
> that points to in-addr.arpa rather than real domain.

-- 
Best Regards,

---

From: Ted Lemon <[email-masked]>
Date: Tue, 8 Jan 2019 22:45:50 -0500

Please bear in mind that you are at the IETF, so if there are technical
objections to your proposal that mean that it doesn't solve the problem
that you are trying to solve, as is the case here, it doesn't matter how
many people want to do what you want to do—it shouldn't get consensus.   In
other words, if you say "I have this problem, and here is what I propose to
do about it," and someone can clearly show that what you propose to do
about it won't work, then the IETF shouldn't be publishing a document
saying to do it that way.

On Tue, Jan 8, 2019 at 10:12 PM Viruthagiri Thirumavalavan <[email-masked]>
wrote:

>> > ietf-smtp@ietf..org <[email-masked]>

---

From: [email-masked]
Date: Tue, 08 Jan 2019 22:57:15 -0500

> recommending both STS and DANE. Again I'm not against them.

Once you have enough DNSSEC to make DANE work, there's no point to
your proposal.

And if you don't have enough DNSSEC to make DANE work, your proposal
doesn't add any *real* security against a MITM.

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Wed, 9 Jan 2019 10:07:15 +0530

Ok thanks guys

---

From: [email-masked]
Date: Wed, 09 Jan 2019 00:56:16 -0500

(warning - long digression on computer security and attacker mindset
follows.  Feel free to hit 'discard' if you're not interested)

> > information if they want it.

And Mark is being nice and glossing over how much recon an attacker is going to
do... But I'm *way* too caffienated for midnight and somewhat bored, so... :)

So.. say I'm a snooper. The thought process goes as follows....

I find that doing a 'traceroute -A' to the target host is often quite enlightening -
between the PTR entries for each hop and looking up the ASN for it, you often
find helpful information even if the final host PTR is obfuscated and the DNS registrar's
entry in WHOIS is less that informative. 'dig dombox.org mx' shows that its
email service is hosted by Google. 'dig dombox.org any' and 'soa' tells me that Cloudflare
is providing DNS. And traceroute tells me that Cloudflare is providing hosting
as well.  And it's on 2 anycast instances (the chances it's on only one instance
that just *happens* to be the *very next* hop once the packets leave Comcast's
network are pretty much zero).

And a minute with google shows that other things served off the same IP addresses
include picshouse2.com, yoodownload.com, and what appears to be at least
3 or 4 other domains that have been naughty and serving up malware.

Probably an F5 load balancer or similar gear in front of a server farm. If I was
serious, I'l point nmap at it and make sure.

Damn. Took me longer to actually *write* all that than it took to do that initial recon. 

If I was serious enough about attacking dombox.org to try to MITM its email,
I'd definitely do a more thorough trawl of DNS to find what other domains
Cloudflare is serving up on those same 2 IP addresses and then a bit of recon
on all the *other* things hosted, and see if any of them have obvious SQL
injections or other weak spots, to get a foothold on the hypervisor or other
side of the load balancer.  Yeah, probably Cloudflare is smart about patching
their hypervisors against Spectre and friends, and the territory behind any
load balancers has properly secured routers and VLAN setup so even if I get
hold of another instance back there, I can't easily leverage it to get
dombox.org's instance.

But who knows... it's worth the effort, even properly run places screw things up
once in a while.

And you'd think that after somebody hijacked the show network at Defcon 16 in
Las Vagas in 2012 and routed it through a server in NYC *and nobody noticed*,
people would be a bit more careful about BGP security issues that make it a lot
easier to MITM a host.

https://www.defcon.org/images/defcon-16/dc16-presentations/defcon-16-pilosov-kapela.pdf
https://www.youtube.com/watch?v=IDoivWHVrGI

But just recently there was discussion on the NANOG list about a nice BGP route
"leak"/"hijack" that routed a lot of traffic that should have stayed in North
America through China Telecom.

https://mailman.nanog.org/pipermail/nanog/2019-January/098721.html

And that's after this nice little escapade... (thread broken in two by the nanog archive)

https://mailman.nanog.org/pipermail/nanog/2018-November/097740.html
https://mailman.nanog.org/pipermail/nanog/2018-December/098051.html

> Ok I missed that one. Good point.

You missed a *bunch* of stuff.  See above. :)

And yes, your attacker *will* at least think about *all* of the above, and
a bunch more....

> I'm not sure whether all snoopers would know all these loopholes.

It's safer to assume they do.  It's also a good idea to assume that snooping
is only part of their plans - that's why I talked a bunch about webservers not
SMTP servers.

I've been doing computer security at least part of my job for 4 decades now.
And I *always* approach it with the assumption that my attacker knows *at
least* as much as I do about the loopholes, because they do it full time every
day, and I spend time doing other stuff, like dealing with petabytes of storage,
problematic users, etc etc. :)

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Wed, 9 Jan 2019 11:35:09 +0530

Thank god. I used Google and Cloudflare. Or you would have hacked me :-)

On a serious note, that was very insightful.

On Wed, Jan 9, 2019 at 11:26 AM <[email-masked]> wrote:

> > > So the snooper just makes a connection over port 26 to the server to
> fill
> > > in the missing

-- 
Best Regards,

---

From: Paul Smith <[email-masked]>
Date: Wed, 9 Jan 2019 09:37:26 +0000

On 09/01/2019 01:01, Viruthagiri Thirumavalavan wrote:
> /mail.example.com <http://mail.example.com> connecting to 
> mail.yahoo.com <http://mail.yahoo.com> with its IP address/
> /yahoo.com <http://yahoo.com> => 220 mail.yahoo.com 
> <http://mail.yahoo.com> Yahoo ESMTP Service Ready/
> /example.com <http://example.com> => EHLO mail.example.com 
> <http://mail.example.com>/
> /yahoo.com <http://yahoo.com> => 250-Hello, nice to meet you, 
> mail.example.com <http://mail.example.com>/
> /yahoo.com <http://yahoo.com> => 250-SIZE 1000000/
> /yahoo.com <http://yahoo.com> => 250-8BITMIME/
> /yahoo.com <http://yahoo.com> => 250 STARTTLS/
> /example.com <http://example.com> => STARTTLS/
> /yahoo.com <http://yahoo.com> => 220 Go ahead/
> /Key exchange happens here and the rest of the email part is encrypted /
> /
> /

No they can't.

BUT, the bit you seem to be missing is that all that info is still 
visible to a MITM attack even with your proposal. Anyone else can 
connect to the same IP/port that they've snooped you connecting to, and 
see the same info, and that info isn't exactly secret anyway.

--

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 9 Jan 2019 20:11:53 +0100

On Tue 08/Jan/2019 19:43:25 +0100 Ted Lemon wrote:
> connection to the server's port 26.  Only if the client knows that the server
> supports TLS can you prevent a downgrade, and then STARTTLS works fine.   So
> you need some secure way of signaling this, e.g. DNSSEC, and if you have that,
> then you don't need a second port allocation.

Correct.  So doing port 26 wouldn't get us more security.  However, it doesn't
seem to get less security either.  I don't see it as a useless complication, it
looks rather like a simplification to me.

Valdis' citation about 60% of SMTP servers is also correct, but indeed it
shouldn't be a problem.  I'd change the line about naming to:

   If a mail server support port 26 (smtps), then they MAY (was "should")
   name their MX server with "smtps-" prefix.

Prefix should never be checked automatically.  Admins every now and then look
at MX names, and if they start to see those prefixes, they may decide to
activate their server test-port-26 option.  Gullible, eh?  However, MTA-STS is
certainly more complicated and costly.  For one thing, you have to pay an extra
mta-sts.example.com certificate (unless you already afforded a wildcard).  For
clients it's much much more work.

*Port 26 is simple*.  Straightforward for servers that already implement 465.
No-brainer for clients.  The only risk is connection timeout on a
non-interactive job.  Does it hurt?

Best
Ale
--

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Jan 2019 14:16:27 -0500

Port 26 requires new operational behavior, so it's not simple.   It
requires knowing that it's available, and trying it.   It requires making
it available.   It requires deploying lots of new software.   And it
requires allocating a reserved port, and reserved ports are scarce.   So
that's not a good reason to do it: essentially we are doing a lot of new
work in order to accomplish something that we could already accomplish
using existing software and doing no new work.

On Wed, Jan 9, 2019 at 2:11 PM Alessandro Vesely <[email-masked]> wrote:

> server

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 9 Jan 2019 20:35:36 +0100

On Wed 09/Jan/2019 20:16:27 +0100 Ted Lemon wrote:

> Port 26 requires new operational behavior, so it's not simple.   It requires
> knowing that it's available, and trying it.   It requires making it available. 
>  It requires deploying lots of new software.

I don't think software is a problem, because on my server (Courier-MTA) I could
do it without even changing a line of code.  Just duplicate 465 settings,
change port number and mandatory login.  For sending, I'd need to set special
routes, which is annoying; adding one line of code is handier.

> And it requires allocating a reserved port, and reserved ports are scarce.

Yes.  And publish an RFC.

> So that's not a good reason to do it: essentially we are doing a lot of new
> work in order to accomplish something that we could already accomplish using
> existing software and doing no new work.

Wouldn't the final scenario be better?

Best
Ale

> On Wed, Jan 9, 2019 at 2:11 PM Alessandro Vesely <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     > On Jan 8, 2019, at 12:23 PM, [email-masked]
>     <mailto:[email-masked]> wrote:
>     mta-sts.example.com <http://mta-sts.example.com> certificate (unless you
>     already afforded a wildcard).  For

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Jan 2019 14:38:04 -0500

No, the final scenario would be that instead of there being one way to
solve the problem, there would be two ways, and then you'd have interop
problems because some people would do it one way and some the other.   And
of course we'd have one less reserved port.  So it's not at all realistic
to be talking about it—it's not going to get consensus, because there's an
obvious technical objection to it.

On Wed, Jan 9, 2019 at 2:35 PM Alessandro Vesely <[email-masked]> wrote:

> requires
> >     >> Hint: If starttls is subject to a downgrade attack, what prevents
> the
> >     same attack
> >     > you need some secure way of signaling this, e.g. DNSSEC, and if
> you have
> >     that,

---

From: Paul Smith <[email-masked]>
Date: Wed, 9 Jan 2019 20:03:16 +0000

> Wouldn't the final scenario be better?

SMTPS on port 26 is realistically no better than STARTTLS on port 25. 
And STARTTLS on port 25 is already widely implemented, widely deployed 
and working. What would be the point of making things more complicated 
with no gain?

Without the downgrade protection you gain precisely nothing except added 
complexity. If you have a method to prevent encryption downgrade (we do) 
you may as well protect STARTTLS downgrade instead of 'port 26 -> 25 
downgrade' and avoid the added complexity.

--

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Wed, 9 Jan 2019 12:37:29 -0800

> and working. What would be the point of making things more complicated 

Devil's advocate question: Do we (the community) care about improved 
connection latency?

My intuition is no; interest in all things SMTP RTT-related has ebbed 
and flowed over the years (pipelining, connection caches, etc.), but it 
never seemed like a big enough issue to be worth burning a port number. 
(On the Web, you've got companies spending millions to shave a few 
milliseconds off RTT, and the single RTT of TLS v1.3 is a Very Big Deal. 
But that's a completely different problem space.)

<csg>

---

From: [email-masked]
Date: Wed, 09 Jan 2019 16:26:45 -0500

> Devil's advocate question: Do we (the community) care about improved 

My intuition says that this proposal doesn't help improve latency, because
the hit you take waiting for a timeout on port 26 to a non-adopter server
is going to overwhelm any savings from the STARTTLS RTT not being
needed.

Has anybody checked what current MTAs do if they're configured to "Deliver mail
to this domain on TLS port nnn" but the listener on nnn isn't a TLS-first but
one that immediately responds with a 220?

---

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

>Devil's advocate question: Do we (the community) care about improved 

Considering that most MTAs check a dozen DNSBLs at connection time
before deciding what to do with the connection, no.

R's,
John

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Thu, 10 Jan 2019 11:40:22 +0530

Hey all, I have some questions about DANE and I have some case to make
regarding my SMTPS proposal.

I still can't wrap my head around DANE.  I understand DANE is trying to be
"your own CA".

DNSSEC already protects my DNS records from spoofing. So I believe all my
DNS records are secure when I enable DNSSEC.

My domain is dombox.org and if I have mx records like

mx1.dombox.org
mx2.dombox.org
mx3.dombox.org
mx4.dombox.org
mx5.dombox.org

then those MX records are already protected from forgery since I have now
enabled DNSSEC.

Now I need to add DANE TLSA record to let the world know that my port 25
supports STARTTLS. So clients can detect downgrade issues.

The TLSA records looks like this.

25._tcp.mx1.dombox.org. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
25._tcp.mx2.dombox.org. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
25._tcp.mx3.dombox.org. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
25._tcp.mx4.dombox.org. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
25._tcp.mx5.dombox.org. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68

I think we can can simplify that part via CNAME record. But, let's not go
there.

Now my first question is, does that "fingerprint" adds any security in a
"Third party CA" system? Or it's there just to be compatible with the DANE
system since DANE is not a mail specific system?

My second question, if my MX records are configured to use google MX
servers (e.g. aspmx.l.google.com) whose job is to configure those DANE TLSA
records?

Google or Me?

I believe it's not my job. Because there is no easy way I can have Google
MX server certificate fingerprint unless google provides it. Even if they
provide it, if google change their certificate for security reasons in the
future, then that's gonna break millions of domains that depends on Google
mail servers. So that would be a poor design.

If I'm not wrong Google is against DNSSEC. So there is no way they are
gonna configure DANE records like this.

25._tcp.aspmx.l.google.com. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
25._tcp.alt1.aspmx.l.google.com. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
25._tcp.alt2.aspmx.l.google.com. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
25._tcp.alt3.aspmx.l.google.com. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
25._tcp.alt4.aspmx.l.google.com. IN TLSA 3 0 1
ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68

Hopefully, That is one of the reason why MTA-STS got introduced.

Even if I love DNSSEC and support it in my domain, Google sets the rules
here since I'm relying on their mail hosting. I have no other way, other
than supporting MTA-STS since google is against DNSSEC.

Please correct me if I'm wrong with those statements.

-------

My above statements might be wrong. But if there is a slightest chance
those are true, isn't my design offers simpler version of the story?

Step 1: If you wanna support port 26, make sure port 25 is secure too. Then
name your records with prefix "smtps-".  If you don't wanna support port
26, but wanna secure only port 25, then name your records with prefix
"starttls-"

Step 2: Enable DNSSEC. If you can't do that, just serve a txt file in a
https server (STS).

First step should be treated as "Basic Security". And second step should be
treated as "Ultimate Security".

Isn't that simple there?

1) No need to rely on DANE here. Just DNSSEC is enough.
2) Google don't have to interfere with your decision here. You can go for
either DNSSEC or STS for authentication since Google's MX records gonna
start with "smtps-" prefix. If you don't go for DNSSEC or STS, it still
fall under "Basic Security"
3) TLSA, CNAME, SRV records very new to the people who used only MX records
before. They don't have to be forced to learn those new records since the
signalling is embedded in the MX records.

MTA-STS needs a HTTPS server.  So you need a hosting and ssl certificates.
You can get both for free these days. For example my website is hosted in
Github. Github offers free hosting for simple html pages. And you can get
SSL certificates for free via LetsEncrypt.

But it's not about tech-savvy folks who knows things. It's about non-tech
savvy folks who just get started via services like GoDaddy. GoDaddy gonna
cross-sell hosting and ssl certificates for this reason rather than guiding
them to get hosting and ssl certificates for free. Why should they?. They
are a For-Profit company. If they start to recommend free alternatives then
their business gonna lose money. So the domain owners are forced to spend
money here.  MTA-STS should be a backup plan who are paranoid about DNSSEC.
But It shouldn't be the main plan.

As for DANE. If a MX record that's protected by DNSSEC says "
aspmx.l.google.com <http://tcp.aspmx.l.google.com/>", then i'm gonna
validate the SSL certificate and make sure the domain matches. Why do we
need DANE for that? If the fingerprint doesn't add any security value and
used only for "we support STARTTLS" signalling and designed that way only
to be compatible with the DANE system, then I think we are complicating
things there.

As for introducing SMTPS on port 26, I already lost the "security"
argument. I cannot go down that road again.

But we can't just ignore Implicit TLS just because it's gonna waste a port.
My proposal at least sends out the positive vibe that the IETF still cares
about email security. Right now by keep patching STARTTLS, we are only
doing "plastic surgery" to the SMTP security.

I'm not sure why people here not backing me up with my SMTPS proposal. The
only person that supports my cause here is Alessandro Vesely.  There are
plenty of people like him out there. They are just not here.

Since no one here to back me up other than Alessandro Vesely, I have to do
some research and bring some comments from the Internet. I'm gonna leave
those comments here, just to bring some thoughts on this.

Just to be clear, I'm not in anyway saying they are all right and you are
all wrong. I'm just trying to present my case here.

And one more thing, I'm new to the IETF. If you are against my proposal and
you are one of the people behind MTA-STS and MTA-DANE related works, please
put that in the disclaimer while objecting my proposal. My proposal tries
to make the job easier for end user and trying to bring something new to
the SMTP world. I just don't want IETF to kill my proposal if people are
all biased.

Here are the comments I sourced from Hacker news.

-------

"The only (weak) argument I can find is that since servers that had a port
465 open also had to keep a port 25 open for compatibility, you could
perform the same downgrade attack by blocking connections to port 465,
which would result in a submission to the port 25. But that's a "if it's
broken let's make sure it remains broken" kind of argument."

https://news.ycombinator.com/item?id=17399079

-------

"How did these committees think that optional, downgradable encryption was
preferable to a standalone, encrypted only port (465)? Were they trying to
save server ports, like if it was a precious resource? Any design decision
I have seen regarding email since 2000 defies common sense. Like I heard
most SMTP implementations do not validate certificates. What good is an
unvalidated certificate? SPF is treated as indicative only or ignored."

https://news.ycombinator.com/item?id=17398280

-------

"True, but the underlying question is still interesting: why isn't there a
similar TLS-only port for MTA-MTA and we all agree to try to connect there
first"

https://news.ycombinator.com/item?id=17400554

-------

"I'm not a big fan of STARTTLS, I'd rather just have implicit TLS (All or
nothing) from the get go."

https://news.ycombinator.com/item?id=17401895

-------

"I appreciate what they're trying to do, and it may improve the status quo,
but we've learned that the push away from implicit SSL/TLS and towards
STARTTLS was wrong. Using one insecure aspect (DNS) to note that you SHOULD
be able to do TLS with my mail server isn't a great solution.
We need to revisit the STARTTLS vs implicit TLS debate in light of the
obvious vulnerability and overhead of starting with plain TCP connections
and then hopefully signalling towards security. HTTPS is obviously implicit
TLS and it works great. We know STARTTLS has issues. Can we not keep going
down the STARTTLS road for email, while going down the implicit TLS road
for other things?"

https://news.ycombinator.com/item?id=17402701

-------

"The problem is partly because we don't have an assigned port for MTA2MTA
implicit TLS."

https://news.ycombinator.com/item?id=17403441

-------

"The main problem with this is that STARTTLS is not anywhere near good
enough, but if it sees high adoption, nobody may bother with something
better in the future because they'll all think "Mission Accomplished.""

https://news.ycombinator.com/item?id=17398335

-------

"I fully agree. It will not achieve anything. FYI, "SMTP Require TLS" was
running on port 465 many years ago.
With many ISPs (and even some VPS) now blocking port 25, it could have been
an opportunity to migrate naturally towards the "new" unencumbered port."

https://news.ycombinator.com/item?id=17397838

-------

"Perhaps fixing STARTTLS is one of those problems where the solution adds
even more problems (and moving parts)."

https://news.ycombinator.com/item?id=17398783

-------

"So there was never really a dedicated TLS port for MTA to begin with?"

https://news.ycombinator.com/item?id=17400128

-------

"Yes - it's a weak argument, and one that's probably been debunked by
looking the way https lifted off recently. My view is if port 465 was still
around today, it would probably get the same level of attention as port 443
has. We could have been at a stage where port 25 could be made
intentionally unavailable (same way we move browsers from http to https)
and everything forced to 465. Email agent developers would be forced to
update their practices as well, no email should be sent over plaintext. At
present, there is no good way to tell your clients you're not accepting
plaintext. STARTTS is from a world where 99% of emails were plaintext."

https://news.ycombinator.com/item?id=17399344

-------

"Apparently 465 is only for mail submission, not MTA-MTA -- but of course
that still leaves the obvious questions of a) why? b) if it must be a
different port, why not make that TLS-only?"

https://news.ycombinator.com/item?id=17400568

-------

"See, at surface value I agree. But at a deeper level I don't. The problem
is too many broken protocols exist via RFC only (dns, smtp, etc). Rather
than violate that, or force it into something it's not, we should be
writing newer, better protocols. The friction against this is huge, mainly
by those who capped out at the previous RFCs, though. Email(well, smtp)
itself is so outdated and broken, I can't believe it's still so widely
used."

https://news.ycombinator.com/item?id=17398011

-------

"I'm sorry, but the problem is more complicated than that.
SSL is not mandatory on either port 25 or 587, and SSL can not be made
mandatory if you follow the RFCs (it can be made mandatory if you tweak
your MTA, but you may lose some mail). Advertising for SSL over DNS means
you trust the DNS records - which you shouldn't without DNSSEC. Even with
it, there can be workarounds that in practice will allow MITMs.

The only real solution is making SSL mandatory, and doing SMTP over SSL as
in the good old days of using stunnel on port 465 to decrypt, then netcat
to forward the output to the MTA running on localhost:25

But that is not standard. Maybe the efforts would be better invested by
changing the standards to have a port where SMTP can not happen at all
without SSL - just like port 465 was, over 10 years ago."

https://news.ycombinator.com/item?id=17397803

-------

"I agree with you, STARTTLS Everywhere is not "a problem". It is not a
solution either - at best a minor improvement."

https://news.ycombinator.com/item?id=17397850

-------

"I consider myself very technical, and know my way around Windows and Linux
pretty well (I've used both for many years), but setting up a mail server
is something I do very infrequently and find complicated to get right when
I do so, especially when getting it working with TLS, DKIM, SPF and spam
filtering."

https://news.ycombinator.com/item?id=17632545

-------

"It would be better to have a TLS connection right at the start. STARTTLS
is less secure. Why hasn't this happened for SMTP?"

https://news.ycombinator.com/item?id=17631820

-------

"Because it's not backwards compatible, and would prevent delivery of a
large amount of email.
We just need a way for domain owners to signal that their domains
definitely accept email over STARTTLS. At that point, senders which
recognise those signals can start to enforce that mail which they send to
those domains MUST use STARTTLS. Fortunately, those signalling methods are
beginning to rise to the surface. We have MTA-STS, and now also a preload
list thanks to StartTLS Everywhere."

https://news.ycombinator.com/item?id=17632756

-------

"All you need is another port in addition to the regular SMTP port. They
are not mutually exclusive."

https://news.ycombinator.com/item?id=17634344

-------

"That is completely insecure. A MITM would just block access to the
tls-on-connect port, forcing the sending host to retry on port 25, where
they would strip the STARTTLS advertisement.
Unless you're recommending to not fall back to port 25 after a failed
connection to the tls-on-connect port. In which case, see the comment you
were replying to where I said it would be backwards incompatible.

Both of the solutions I mentioned are backwards compatible, and protected
from a similar downgrade situation." (Refering to MTA-STS and StartTLS
Everywhere)

https://news.ycombinator.com/item?id=17648703

-------

"Right, I should have said that I was recommending not ever sending on 25.
The STARTTLS mitm is just too easy for large attackers.
IMHO, being backwards compatible is necessary for a transition period. The
messaging to SMTP operators should be... get on board, or you are going to
start losing mail in 1 year.

Even Chrome is going to show all http as insecure in the very near future.
Which reminds me... I need to get all my sites upgraded."

https://news.ycombinator.com/item?id=17655371

-------

"MTA-STS is pretty ill-conceived. In essence it mandates that compliant
MTAs also run a concurrent web service. The authors do not explain why this
is useful instead of the simpler approach -- enhance SMTP to reject mail on
port 25 with a NEEDS-TLS error, then fall back to implicit TLS (what port
465 was originally for)."

"The system needs to be able to authenticate a DNS-resolved endpoint. HTTPS
provides this.
Of course, they could have gone with DNSSEC, but HTTPS has the virtue of
solving the same problem (modulo proper configuration), while also being
more widely deployed and better understood."

"HTTPS does not provide authentication sufficiently well to put every egg
in its basket.
As for "better understood," the authors of this standard work for Google,
Verizon, Microsoft, and Comcast. Combined they probably serve most of the
email in the western hemisphere.

There is no excuse for overcomplicating a proposed standard -- and "we have
this stuff lying around" is no exception. This plan has the effect of
causing a networking protocol to depend on an entire series of unrelated
networking protocols.

It does not bode well for the future of independent email operators and it
provides no path forward for integrating existing devices. It pushes many,
many extra steps onto client devices, necessitating entire additional
libraries of software to deal with them. That's not a problem for companies
with tens of thousands of developers at their beck and call -- but it is
only going to raise the barrier-to-entry of operating an independent
service."

"Those sound like reasonable objections. Are you posting them to the
discussions involved in shaping and ratifying the proposed standard?"

https://news.ycombinator.com/item?id=16279241

------

Back to the original discussion, I totally agree with Mark Andrews, Valdis
Kletnieks and others that Implicit TLS doesn't offer any additional
security than a downgrade protected STARTTLS.

But, you guys are like movie critics. You go to watch movies just to find
flaws. But an average movie goers go for entertainment.  For 20 years, we
already established with the fact STARTTLS is not secure. If you wanna sell
the same thing again by saying it's secure, then you have to go into detail
and explaining why it's secure. So I believe it's much easier to SELL
"Implicit TLS" is secure than STARTTLS is secure.

My SMTPS proposal is an optional proposal. Nobody is forced to setup SMTPS.
People like me, Alessandro Vesely and many other hacker news users would
love to support Implicit TLS in SMTP even though the same level security
can be achieved via STATTLS. If something is better (at least in perceiving
this), why against it? Also note companies like google still do offer both
Implicit TLS and Opportunistic TLS for submission. So it can't hurt to have
Implicit TLS in SMTP too.

My apologies for starting the discussion again.

Thanks

---

From: Дилян Палаузов <[email-masked]>
Date: Thu, 10 Jan 2019 06:18:31 +0000

Hello,

just as there is HTTP Strict Transport Security (HSTS) preload list — a text file full with hosts that are dedicated to
deliver all content over HTTPS, there is also “MTA Strict Transport Security (MTA-STS) preload list” — a text file
containg domains and subdomains, that are committed to offer STARTTLS.

  https://starttls-everywhere.org/

Providing that the implementation of MTA-STS and MTA-DANE is not simple, integrating the STARTTLS everywhere list is
simpler.

Regards
  Дилян

---

From: Дилян Палаузов <[email-masked]>
Date: Thu, 10 Jan 2019 06:47:58 +0000

Hello Viruthagiri,

Concerning DANE I propose you read RFC 6698, RFC 7218, RFC 7671, RFC 7672. The latter shall answer your question.

In your particular case, you have to find first a statement from Google, that they cannot disable anytime at their
disposal STARTTLS, and before this is done at your place I would not publish information that to your domain only
secured connections can be made.  In particular I would not publish MTA-STS information.

I have read the DANE RFCs long time ago and I do not remember every detail.  In theory you can publish the IP addresses
in charge for your emails under your domain and sign that A(AAA) records.  The hash of the used certificates is
published over TLSA.  However certificates are changed from time to time and before the change you have to publish in
DNS both the current and the next certificate, as you correctly recognized.  Then wait until the next certificate is
distributed over DNS and only then switch the STARTTLS certificate.  So you need in this scenario also to know when the
certificates will be changed and to know the certificate that is going to be applied next.  I do not know whether this
information is published, but there are no compelling reasons not to do so.

If you want to get a feeling how SMTP works in practice I recommend you run your own mail server.  If you want to use a
provider, find one that matches your needs.

Regards
  Дилян

On Thu, 2019-01-10 at 11:40 +0530, Viruthagiri Thirumavalavan wrote:
> Hey all, I have some questions about DANE and I have some case to make regarding my SMTPS proposal.
> 
> I still can't wrap my head around DANE.  I understand DANE is trying to be "your own CA". 
> 
> DNSSEC already protects my DNS records from spoofing. So I believe all my DNS records are secure when I enable DNSSEC. 
> 
> then those MX records are already protected from forgery since I have now enabled DNSSEC. 
> 
> Now I need to add DANE TLSA record to let the world know that my port 25 supports STARTTLS. So clients can detect downgrade issues.
> 
> 25._tcp.mx1.dombox.org. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 25._tcp.mx2.dombox.org. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 25._tcp.mx3.dombox.org. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 25._tcp.mx4.dombox.org. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 25._tcp.mx5.dombox.org. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 
> I think we can can simplify that part via CNAME record. But, let's not go there.
> 
> Now my first question is, does that "fingerprint" adds any security in a "Third party CA" system? Or it's there just to be compatible with the DANE system since DANE is not a mail specific system? 
> 
> My second question, if my MX records are configured to use google MX servers (e.g. aspmx.l.google.com) whose job is to configure those DANE TLSA records?
> 
> Google or Me?
> 
> I believe it's not my job. Because there is no easy way I can have Google MX server certificate fingerprint unless google provides it. Even if they provide it, if google change their certificate for security reasons in the future, then that's gonna break millions of domains that depends on Google mail servers. So that would be a poor design.
> 
> If I'm not wrong Google is against DNSSEC. So there is no way they are gonna configure DANE records like this.
> 
> 25._tcp.aspmx.l.google.com. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 25._tcp.alt1..aspmx.l.google.com. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 25._tcp.alt2.aspmx.l.google.com. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 25._tcp.alt3.aspmx.l.google.com. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 25._tcp.alt4.aspmx.l.google.com. IN TLSA 3 0 1 ae822a14fd5e56c213eeeb5d6755556980caf4c3f2531c1ec8eca3076f9b7e68
> 
> Even if I love DNSSEC and support it in my domain, Google sets the rules here since I'm relying on their mail hosting. I have no other way, other than supporting MTA-STS since google is against DNSSEC.
> 
> My above statements might be wrong. But if there is a slightest chance those are true, isn't my design offers simpler version of the story?
> 
> Step 1: If you wanna support port 26, make sure port 25 is secure too. Then name your records with prefix "smtps-".  If you don't wanna support port 26, but wanna secure only port 25, then name your records with prefix "starttls-" 
> 
> Step 2: Enable DNSSEC. If you can't do that, just serve a txt file in a https server (STS).
> 
> First step should be treated as "Basic Security". And second step should be treated as "Ultimate Security". 
> 
> Isn't that simple there? 
> 
> 2) Google don't have to interfere with your decision here. You can go for either DNSSEC or STS for authentication since Google's MX records gonna start with "smtps-" prefix. If you don't go for DNSSEC or STS, it still fall under "Basic Security"
> 3) TLSA, CNAME, SRV records very new to the people who used only MX records before. They don't have to be forced to learn those new records since the signalling is embedded in the MX records.
> 
> MTA-STS needs a HTTPS server.  So you need a hosting and ssl certificates. You can get both for free these days. For example my website is hosted in Github. Github offers free hosting for simple html pages. And you can get SSL certificates for free via LetsEncrypt. 
> 
> But it's not about tech-savvy folks who knows things. It's about non-tech savvy folks who just get started via services like GoDaddy. GoDaddy gonna cross-sell hosting and ssl certificates for this reason rather than guiding them to get hosting and ssl certificates for free. Why should they?. They are a For-Profit company. If they start to recommend free alternatives then their business gonna lose money. So the domain owners are forced to spend money here.  MTA-STS should be a backup plan who are paranoid about DNSSEC. But It shouldn't be the main plan.
> 
> As for DANE. If a MX record that's protected by DNSSEC says "aspmx.l.google.com", then i'm gonna validate the SSL certificate and make sure the domain matches. Why do we need DANE for that? If the fingerprint doesn't add any security value and used only for "we support STARTTLS" signalling and designed that way only to be compatible with the DANE system, then I think we are complicating things there.
> 
> As for introducing SMTPS on port 26, I already lost the "security" argument. I cannot go down that road again. 
> 
> But we can't just ignore Implicit TLS just because it's gonna waste a port. My proposal at least sends out the positive vibe that the IETF still cares about email security. Right now by keep patching STARTTLS, we are only doing "plastic surgery" to the SMTP security.  
> 
> I'm not sure why people here not backing me up with my SMTPS proposal. The only person that supports my cause here is Alessandro Vesely.  There are plenty of people like him out there. They are just not here. 
> 
> Since no one here to back me up other than Alessandro Vesely, I have to do some research and bring some comments from the Internet. I'm gonna leave those comments here, just to bring some thoughts on this. 
> 
> Just to be clear, I'm not in anyway saying they are all right and you are all wrong. I'm just trying to present my case here.
> 
> And one more thing, I'm new to the IETF. If you are against my proposal and you are one of the people behind MTA-STS and MTA-DANE related works, please put that in the disclaimer while objecting my proposal. My proposal tries to make the job easier for end user and trying to bring something new to the SMTP world. I just don't want IETF to kill my proposal if people are all biased. 
> 
> "The only (weak) argument I can find is that since servers that had a port 465 open also had to keep a port 25 open for compatibility, you could perform the same downgrade attack by blocking connections to port 465, which would result in a submission to the port 25. But that's a "if it's broken let's make sure it remains broken" kind of argument."
> 
> "How did these committees think that optional, downgradable encryption was preferable to a standalone, encrypted only port (465)? Were they trying to save server ports, like if it was a precious resource? Any design decision I have seen regarding email since 2000 defies common sense. Like I heard most SMTP implementations do not validate certificates. What good is an unvalidated certificate? SPF is treated as indicative only or ignored."
> 
> "True, but the underlying question is still interesting: why isn't there a similar TLS-only port for MTA-MTA and we all agree to try to connect there first"
> 
> "I'm not a big fan of STARTTLS, I'd rather just have implicit TLS (All or nothing) from the get go."
> 
> "I appreciate what they're trying to do, and it may improve the status quo, but we've learned that the push away from implicit SSL/TLS and towards STARTTLS was wrong. Using one insecure aspect (DNS) to note that you SHOULD be able to do TLS with my mail server isn't a great solution.
> We need to revisit the STARTTLS vs implicit TLS debate in light of the obvious vulnerability and overhead of starting with plain TCP connections and then hopefully signalling towards security. HTTPS is obviously implicit TLS and it works great. We know STARTTLS has issues. Can we not keep going down the STARTTLS road for email, while going down the implicit TLS road for other things?"
> 
> "The problem is partly because we don't have an assigned port for MTA2MTA implicit TLS."
> 
> "The main problem with this is that STARTTLS is not anywhere near good enough, but if it sees high adoption, nobody may bother with something better in the future because they'll all think "Mission Accomplished.""
> 
> "I fully agree. It will not achieve anything. FYI, "SMTP Require TLS" was running on port 465 many years ago.
> With many ISPs (and even some VPS) now blocking port 25, it could have been an opportunity to migrate naturally towards the "new" unencumbered port."
> 
> "Perhaps fixing STARTTLS is one of those problems where the solution adds even more problems (and moving parts)."
> 
> "Yes - it's a weak argument, and one that's probably been debunked by looking the way https lifted off recently. My view is if port 465 was still around today, it would probably get the same level of attention as port 443 has. We could have been at a stage where port 25 could be made intentionally unavailable (same way we move browsers from http to https) and everything forced to 465. Email agent developers would be forced to update their practices as well, no email should be sent over plaintext. At present, there is no good way to tell your clients you're not accepting plaintext. STARTTS is from a world where 99% of emails were plaintext."
> 
> "Apparently 465 is only for mail submission, not MTA-MTA -- but of course that still leaves the obvious questions of a) why? b) if it must be a different port, why not make that TLS-only?"
> 
> "See, at surface value I agree. But at a deeper level I don't. The problem is too many broken protocols exist via RFC only (dns, smtp, etc). Rather than violate that, or force it into something it's not, we should be writing newer, better protocols. The friction against this is huge, mainly by those who capped out at the previous RFCs, though. Email(well, smtp) itself is so outdated and broken, I can't believe it's still so widely used."
> 
> SSL is not mandatory on either port 25 or 587, and SSL can not be made mandatory if you follow the RFCs (it can be made mandatory if you tweak your MTA, but you may lose some mail). Advertising for SSL over DNS means you trust the DNS records - which you shouldn't without DNSSEC. Even with it, there can be workarounds that in practice will allow MITMs.
> 
> The only real solution is making SSL mandatory, and doing SMTP over SSL as in the good old days of using stunnel on port 465 to decrypt, then netcat to forward the output to the MTA running on localhost:25
> 
> But that is not standard. Maybe the efforts would be better invested by changing the standards to have a port where SMTP can not happen at all without SSL - just like port 465 was, over 10 years ago."
> 
> "I agree with you, STARTTLS Everywhere is not "a problem". It is not a solution either - at best a minor improvement."
> 
> "I consider myself very technical, and know my way around Windows and Linux pretty well (I've used both for many years), but setting up a mail server is something I do very infrequently and find complicated to get right when I do so, especially when getting it working with TLS, DKIM, SPF and spam filtering."
> 
> "It would be better to have a TLS connection right at the start. STARTTLS is less secure. Why hasn't this happened for SMTP?"
> 
> "Because it's not backwards compatible, and would prevent delivery of a large amount of email.
> We just need a way for domain owners to signal that their domains definitely accept email over STARTTLS. At that point, senders which recognise those signals can start to enforce that mail which they send to those domains MUST use STARTTLS. Fortunately, those signalling methods are beginning to rise to the surface. We have MTA-STS, and now also a preload list thanks to StartTLS Everywhere."
> 
> "All you need is another port in addition to the regular SMTP port. They are not mutually exclusive."
> 
> "That is completely insecure. A MITM would just block access to the tls-on-connect port, forcing the sending host to retry on port 25, where they would strip the STARTTLS advertisement.
> Unless you're recommending to not fall back to port 25 after a failed connection to the tls-on-connect port. In which case, see the comment you were replying to where I said it would be backwards incompatible.
> 
> Both of the solutions I mentioned are backwards compatible, and protected from a similar downgrade situation." (Refering to MTA-STS and StartTLS Everywhere)
> 
> "Right, I should have said that I was recommending not ever sending on 25. The STARTTLS mitm is just too easy for large attackers.
> IMHO, being backwards compatible is necessary for a transition period. The messaging to SMTP operators should be... get on board, or you are going to start losing mail in 1 year.
> 
> Even Chrome is going to show all http as insecure in the very near future. Which reminds me... I need to get all my sites upgraded."
> 
> "MTA-STS is pretty ill-conceived. In essence it mandates that compliant MTAs also run a concurrent web service. The authors do not explain why this is useful instead of the simpler approach -- enhance SMTP to reject mail on port 25 with a NEEDS-TLS error, then fall back to implicit TLS (what port 465 was originally for)."
> 
> "The system needs to be able to authenticate a DNS-resolved endpoint. HTTPS provides this.
> Of course, they could have gone with DNSSEC, but HTTPS has the virtue of solving the same problem (modulo proper configuration), while also being more widely deployed and better understood."
> 
> "HTTPS does not provide authentication sufficiently well to put every egg in its basket.
> As for "better understood," the authors of this standard work for Google, Verizon, Microsoft, and Comcast. Combined they probably serve most of the email in the western hemisphere.
> 
> There is no excuse for overcomplicating a proposed standard -- and "we have this stuff lying around" is no exception. This plan has the effect of causing a networking protocol to depend on an entire series of unrelated networking protocols.
> 
> It does not bode well for the future of independent email operators and it provides no path forward for integrating existing devices. It pushes many, many extra steps onto client devices, necessitating entire additional libraries of software to deal with them. That's not a problem for companies with tens of thousands of developers at their beck and call -- but it is only going to raise the barrier-to-entry of operating an independent service."
> 
> "Those sound like reasonable objections. Are you posting them to the discussions involved in shaping and ratifying the proposed standard?"
> 
> Back to the original discussion, I totally agree with Mark Andrews, Valdis Kletnieks and others that Implicit TLS doesn't offer any additional security than a downgrade protected STARTTLS. 
> 
> But, you guys are like movie critics. You go to watch movies just to find flaws. But an average movie goers go for entertainment.  For 20 years, we already established with the fact STARTTLS is not secure. If you wanna sell the same thing again by saying it's secure, then you have to go into detail and explaining why it's secure. So I believe it's much easier to SELL "Implicit TLS" is secure than STARTTLS is secure.
> 
> My SMTPS proposal is an optional proposal. Nobody is forced to setup SMTPS. People like me, Alessandro Vesely and many other hacker news users would love to support Implicit TLS in SMTP even though the same level security can be achieved via STATTLS. If something is better (at least in perceiving this), why against it? Also note companies like google still do offer both Implicit TLS and Opportunistic TLS for submission. So it can't hurt to have Implicit TLS in SMTP too.
>

---

From: Viruthagiri Thirumavalavan <[email-masked]>
Date: Thu, 10 Jan 2019 12:34:47 +0530

Thanks for the info Дилян

Much appreciated.

On Thu, Jan 10, 2019 at 12:18 PM Дилян Палаузов <[email-masked]>
wrote:

> In your particular case, you have to find first a statement from Google,
> that they cannot disable anytime at their
> disposal STARTTLS, and before this is done at your place I would not
> publish information that to your domain only
> I have read the DANE RFCs long time ago and I do not remember every
> detail.  In theory you can publish the IP addresses
> published over TLSA.  However certificates are changed from time to time
> and before the change you have to publish in
> DNS both the current and the next certificate, as you correctly
> recognized.  Then wait until the next certificate is
> distributed over DNS and only then switch the STARTTLS certificate.  So
> you need in this scenario also to know when the
> certificates will be changed and to know the certificate that is going to
> be applied next.  I do not know whether this
> If you want to get a feeling how SMTP works in practice I recommend you
> run your own mail server.  If you want to use a
> > DNSSEC already protects my DNS records from spoofing. So I believe all
> my DNS records are secure when I enable DNSSEC.
> >
> servers (e.g. aspmx.l.google.com) whose job is to configure those DANE
> TLSA records?
> >
> > Google or Me?
> >
> > I believe it's not my job. Because there is no easy way I can have
> Google MX server certificate fingerprint unless google provides it. Even if
> they provide it, if google change their certificate for security reasons in
> the future, then that's gonna break millions of domains that depends on
> Google mail servers. So that would be a poor design.
> >
> > 25._tcp.alt1..aspmx.l.google.com. IN TLSA 3 0 1
> > Step 1: If you wanna support port 26, make sure port 25 is secure too.
> Then name your records with prefix "smtps-".  If you don't wanna support
> port 26, but wanna secure only port 25, then name your records with prefix
> "starttls-"
> >
> > 2) Google don't have to interfere with your decision here. You can go
> for either DNSSEC or STS for authentication since Google's MX records gonna
> > 3) TLSA, CNAME, SRV records very new to the people who used only MX
> records before. They don't have to be forced to learn those new records
> since the signalling is embedded in the MX records.
> >
> > MTA-STS needs a HTTPS server.  So you need a hosting and ssl
> certificates. You can get both for free these days. For example my website
> is hosted in Github. Github offers free hosting for simple html pages. And
> you can get SSL certificates for free via LetsEncrypt.
> >
> > But it's not about tech-savvy folks who knows things. It's about
> non-tech savvy folks who just get started via services like GoDaddy.
> GoDaddy gonna cross-sell hosting and ssl certificates for this reason
> rather than guiding them to get hosting and ssl certificates for free. Why
> should they?. They are a For-Profit company. If they start to recommend
> free alternatives then their business gonna lose money. So the domain
> owners are forced to spend money here.  MTA-STS should be a backup plan who
> are paranoid about DNSSEC. But It shouldn't be the main plan.
> >
> aspmx.l.google.com", then i'm gonna validate the SSL certificate and make
> sure the domain matches. Why do we need DANE for that? If the fingerprint
> doesn't add any security value and used only for "we support STARTTLS"
> signalling and designed that way only to be compatible with the DANE
> system, then I think we are complicating things there.
> >
> > But we can't just ignore Implicit TLS just because it's gonna waste a
> port. My proposal at least sends out the positive vibe that the IETF still
> cares about email security. Right now by keep patching STARTTLS, we are
> only doing "plastic surgery" to the SMTP security.
> >
> > I'm not sure why people here not backing me up with my SMTPS proposal.
> The only person that supports my cause here is Alessandro Vesely.  There
> are plenty of people like him out there. They are just not here.
> >
> > Since no one here to back me up other than Alessandro Vesely, I have to
> do some research and bring some comments from the Internet. I'm gonna leave
> > Just to be clear, I'm not in anyway saying they are all right and you
> are all wrong. I'm just trying to present my case here.
> >
> > And one more thing, I'm new to the IETF. If you are against my proposal
> and you are one of the people behind MTA-STS and MTA-DANE related works,
> please put that in the disclaimer while objecting my proposal. My proposal
> tries to make the job easier for end user and trying to bring something new
> to the SMTP world. I just don't want IETF to kill my proposal if people are
> all biased.
> >
> > "The only (weak) argument I can find is that since servers that had a
> port 465 open also had to keep a port 25 open for compatibility, you could
> > "How did these committees think that optional, downgradable encryption
> was preferable to a standalone, encrypted only port (465)? Were they trying
> to save server ports, like if it was a precious resource? Any design
> decision I have seen regarding email since 2000 defies common sense. Like I
> heard most SMTP implementations do not validate certificates. What good is
> an unvalidated certificate? SPF is treated as indicative only or ignored."
> >
> > "True, but the underlying question is still interesting: why isn't there
> a similar TLS-only port for MTA-MTA and we all agree to try to connect
> there first"
> >
> > "I appreciate what they're trying to do, and it may improve the status
> quo, but we've learned that the push away from implicit SSL/TLS and towards
> > With many ISPs (and even some VPS) now blocking port 25, it could have
> been an opportunity to migrate naturally towards the "new" unencumbered
> port."
> >
> > "Perhaps fixing STARTTLS is one of those problems where the solution
> adds even more problems (and moving parts)."
> >
> > "Apparently 465 is only for mail submission, not MTA-MTA -- but of
> course that still leaves the obvious questions of a) why? b) if it must be
> a different port, why not make that TLS-only?"
> >
> > "See, at surface value I agree. But at a deeper level I don't. The
> problem is too many broken protocols exist via RFC only (dns, smtp, etc).
> Rather than violate that, or force it into something it's not, we should be
> > The only real solution is making SSL mandatory, and doing SMTP over SSL
> as in the good old days of using stunnel on port 465 to decrypt, then
> netcat to forward the output to the MTA running on localhost:25
> >
> > "I consider myself very technical, and know my way around Windows and
> Linux pretty well (I've used both for many years), but setting up a mail
> server is something I do very infrequently and find complicated to get
> right when I do so, especially when getting it working with TLS, DKIM, SPF
> and spam filtering."
> >
> > "It would be better to have a TLS connection right at the start.
> STARTTLS is less secure. Why hasn't this happened for SMTP?"
> >
> > Both of the solutions I mentioned are backwards compatible, and
> protected from a similar downgrade situation." (Refering to MTA-STS and
> StartTLS Everywhere)
> >
> > "Right, I should have said that I was recommending not ever sending on
> 25. The STARTTLS mitm is just too easy for large attackers.
> > IMHO, being backwards compatible is necessary for a transition period.
> The messaging to SMTP operators should be... get on board, or you are going
> to start losing mail in 1 year.
> >
> > Even Chrome is going to show all http as insecure in the very near
> future. Which reminds me... I need to get all my sites upgraded."
> >
> > As for "better understood," the authors of this standard work for
> Google, Verizon, Microsoft, and Comcast. Combined they probably serve most
> of the email in the western hemisphere.
> >
> > There is no excuse for overcomplicating a proposed standard -- and "we
> have this stuff lying around" is no exception. This plan has the effect of
> > It does not bode well for the future of independent email operators and
> it provides no path forward for integrating existing devices. It pushes
> many, many extra steps onto client devices, necessitating entire additional
> > Back to the original discussion, I totally agree with Mark Andrews,
> Valdis Kletnieks and others that Implicit TLS doesn't offer any additional
> > But, you guys are like movie critics. You go to watch movies just to
> find flaws. But an average movie goers go for entertainment.  For 20 years,
> we already established with the fact STARTTLS is not secure. If you wanna
> sell the same thing again by saying it's secure, then you have to go into
> detail and explaining why it's secure. So I believe it's much easier to
> SELL "Implicit TLS" is secure than STARTTLS is secure.
> >
> > My SMTPS proposal is an optional proposal. Nobody is forced to setup
> SMTPS. People like me, Alessandro Vesely and many other hacker news users
> would love to support Implicit TLS in SMTP even though the same level
> security can be achieved via STATTLS. If something is better (at least in
> perceiving this), why against it? Also note companies like google still do
> offer both Implicit TLS and Opportunistic TLS for submission. So it can't
> hurt to have Implicit TLS in SMTP too.
> >

-- 
Best Regards,

---

From: Evert Mouw <[email-masked]>
Date: Thu, 17 Jan 2019 10:43:41 +0100

Hi,

Yeah and I'm one of them. I run my private mailserver for 3 users, one 
domain name for each.

On 07/01/2019 12.34, Paul Smith wrote:
 > Note that port 465 is defined as for SMTPS for *submission*, so it's 
the SMTPS version of 587, not the SMTPS version of 25.

That is correct, but for most mailservers relaying is disabled anyway, 
so in practice even port 25 has become a submission gate. Also, you 
could configure port 465 to allow relaying... out of the box many mail 
daemons allow this, e.g. I "submit" my outgoing mail to 465 using 
Postfix. It is messy.

 > non-interactive job.  Does it hurt?

Exactly. Also, it makes it easier to recognize a secured mail transport. 
No possible plaintext as with STARTTLS (when the latter fails, mail 
could proceed over an unencrypted transport).

connection latency?

I do.

 > is going to overwhelm any savings from the STARTTLS RTT not being

Good point. I would love a MXS record (Mail eXchanger Secure). Maybe 
such a MXS SHOULD be an alias to an already existent MX record.

As for the port number: if port 24 is already reserved for private mail 
systems (!! so no loss of port numbers !!), but not used anymore, it 
would also make a good candidate. I like the lower number, "try 24 
before 25", but port 26 makes sense too. It makes way more sense (to me 
at least) to have both port numbers in one range, be it 25-25 or 25-26.

One of the benefits of a TLS-only port is the non-dependency on DNSSEC, 
DANE, and whatnot. It is *simple*, easy to implement (by using e.g. an 
SSL wrapper), fast, and pleasing to the eye.

Of course this matter doesn't prelude the end of the world ;-)

Regards, Evert

  _______________
< Send me mail! >
  ---------------
         \   ^__^
          \  (oo)\_______
             (__)\       )\/\
                 ||----w |
                 ||     ||

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Jan 2019 22:57:05 +1100

> On 17 Jan 2019, at 8:43 pm, Evert Mouw <post=[email-masked]> wrote:
> 
> Hi,
> 
> > There are people out there who has personal websites like firstnamelastname.com and email address like [email-masked]
> 
> Yeah and I'm one of them. I run my private mailserver for 3 users, one domain name for each.
> 
> > Note that port 465 is defined as for SMTPS for *submission*, so it's the SMTPS version of 587, not the SMTPS version of 25.
> 
> That is correct, but for most mailservers relaying is disabled anyway, so in practice even port 25 has become a submission gate. Also, you could configure port 465 to allow relaying... out of the box many mail daemons allow this, e.g. I "submit" my outgoing mail to 465 using Postfix. It is messy.
> 
> Exactly. Also, it makes it easier to recognize a secured mail transport. No possible plaintext as with STARTTLS (when the latter fails, mail could proceed over an unencrypted transport).
> 
> > Devil's advocate question: Do we (the community) care about improved connection latency?
> 
> I do.
> 
> Good point. I would love a MXS record (Mail eXchanger Secure). Maybe such a MXS SHOULD be an alias to an already existent MX record.
> 
> As for the port number: if port 24 is already reserved for private mail systems (!! so no loss of port numbers !!), but not used anymore, it would also make a good candidate. I like the lower number, "try 24 before 25", but port 26 makes sense too. It makes way more sense (to me at least) to have both port numbers in one range, be it 25-25 or 25-26.
> 
> One of the benefits of a TLS-only port is the non-dependency on DNSSEC, DANE, and whatnot. It is *simple*, easy to implement (by using e.g. an SSL wrapper), fast, and pleasing to the eye.

DNSSEC is STILL needed with a TLS only port.  You have no TRUSTED name to pass to TLS to check the server certificate against without it.

SMTP is not HTTP.  SMTP has a different set of security properties to HTTP.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Jan 2019 10:26:25 -0500

Indeed, if we added MXS and secured it with DNSSEC, port 25 with STARTTLS
would have the same security properties as port 26 with TLS- from the
start; in neither case would a conforming implementation connection without
a successful TLS handshake.

On Thu, Jan 17, 2019 at 6:57 AM Mark Andrews <[email-masked]> wrote:

> so in practice even port 25 has become a submission gate. Also, you could
> configure port 465 to allow relaying... out of the box many mail daemons
> allow this, e.g. I "submit" my outgoing mail to 465 using Postfix. It is
> messy.
> >
> No possible plaintext as with STARTTLS (when the latter fails, mail could
> proceed over an unencrypted transport).
> >
> systems (!! so no loss of port numbers !!), but not used anymore, it would
> also make a good candidate. I like the lower number, "try 24 before 25",
> but port 26 makes sense too. It makes way more sense (to me at least) to
> have both port numbers in one range, be it 25-25 or 25-26.
> >
> DANE, and whatnot. It is *simple*, easy to implement (by using e.g. an SSL
> wrapper), fast, and pleasing to the eye.
>
> DNSSEC is STILL needed with a TLS only port.  You have no TRUSTED name to
> pass to TLS to check the server certificate against without it.
>