Re: SMTP Over TLS on Port 26 - Implicit TLS Proposal [Feedback Request]

[Viruthagiri Thirumavalavan <giri () dombox org>]

> To the OP - what's the point of hiding the hostname in the smtp banner?
> You already know from the dns. Concerned about the MTA version? You can
> configure postfix to claim it is exchange or avian carrier for that matter


I was concerned about the Brand name right next to the 220 hostname example
I posted earlier. I thought it would offer little more privacy. I was wrong.

So - given that multiple people have explained to you on the ietf-smtp list
> that there's no really sensitive info before STARTTLS, what *exactly* does
> your proposal buy us?  What *real* problem is port 26 fixing?
> And is this something that *you* think is a problem, or that somebody who
> runs an actual production mail system thinks is a problem?


Thanks Mr. Kletnieks,

Nice to meet you again. [To everyone else - he is one of the nicest person
who provided suggestions in ietf-smtp]

When I proposed I thought this was an issue. But seem like it's not. What
I'm looking for here is will there be any additional pros if we introduce
Implicit TLS?

Pros of introducing Implicit TLS:
+ Falls under Best Practices
+ Sets an early date to deprecate Opportunistic TLS in the future. (e.g. 20
years from now)
+ Seems like it's what the world wants.

Cons of introducing Implicit TLS:
- Wastes a port
- ISP needs to add little code to block port 26

Well, the summary on the ietf-smtp list was that the new port doesn't
> actually
> buy you anything unless you have DANE, and once you have DANE, the new port
> doesn't add anything.
> The conclusion is that we should be deploying DANE more rather than
> burning a
> port.
> Not sure why you expect to hear much differently from NANOG.


I improved my proposal a lot based on feedback I received from people like
you. My proposal doesn't rely on DANE. Only DNSSEC. Even for that part, it
doesn't mandates that.

When example.com mails are third party hosted, example.com needs DNSSEC and
third party mail servers (e.g. Google) needs DNSSEC+DANE. But google seem
like it's not interested in DNSSEC. Thus Google provides a DANE alternative
called MTA-STS.

Let's say my domain supports DNSSEC. If my domain mails are hosted in
Google, then I have no other way other than going for MTA-STS.

MTA-STS needs another https server just for the sake of mail security.

My proposal just changes that. Google gonna name their MX servers with
starttls- prefix. And now example.com can protect MX record spoofing via
DNSSEC.

My point is, the signalling mechanism is handed over to third party mail
providers like Google in DANE. My solution embeds the signalling mechanism
in the hostname. Thus google don't have to evangelise MTA-STS to their
millions of customers.

Please correct me if I'm wrong with those statements

On Sat, Jan 12, 2019 at 10:36 AM <valdis.kletnieks () vt edu> wrote:

> On Sat, 12 Jan 2019 09:45:12 +0530, Viruthagiri Thirumavalavan said:
>
> > But I still want the future of email to adopt Implicit TLS. So someday we
> > can kill Opportunistic TLS. I already lost the case for security. So my
> > smtps part of the proposal not gonna fly. I'm just here to learn whether
> > Implicit TLS can offer anything better than Opportunistic TLS that's
> worth
> > wasting a port.
>
> Well, the summary on the ietf-smtp list was that the new port doesn't
> actually
> buy you anything unless you have DANE, and once you have DANE, the new port
> doesn't add anything.
>
> The conclusion is that we should be deploying DANE more rather than
> burning a
> port.
>
> Not sure why you expect to hear much differently from NANOG.


-- 
Best Regards,

Viruthagiri Thirumavalavan
Dombox, Inc.