DevHeads.net

FWIW, port 465 gets standards-track blessing from RFC8314

<a href="https://tools.ietf.org/html/rfc8314#section-3.3" title="https://tools.ietf.org/html/rfc8314#section-3.3">https://tools.ietf.org/html/rfc8314#section-3.3</a>

The STARTTLS mechanism on port 587 is relatively widely deployed due
to the situation with port 465 (discussed in Section 7.3). This
differs from IMAP and POP services where Implicit TLS is more widely
deployed on servers than STARTTLS. It is desirable to migrate core
protocols used by MUA software to Implicit TLS over time, for
consistency as well as for the additional reasons discussed in
Appendix A. However, to maximize the use of encryption for
submission, it is desirable to support both mechanisms for Message
Submission over TLS for a transition period of several years. As a
result, clients and servers SHOULD implement both STARTTLS on
port 587 and Implicit TLS on port 465 for this transition period.
Note that there is no significant difference between the security
properties of STARTTLS on port 587 and Implicit TLS on port 465 if
the implementations are correct and if both the client and the server
are configured to require successful negotiation of TLS prior to
Message Submission.

It remains to be seen whether the new RFC actually changes practices in
the field, but there is now some "official" support for the born-again
port 465 "submissions" service.

Comments

Re: FWIW, port 465 gets standards-track blessing from RFC8314

By LuKreme at 02/12/2018 - 21:14

On 2018-02-11 (15:12 MST), Viktor Dukhovni <postfix- ... at dukhovni dot org> wrote:
I can't think of a single reason to have two submission ports.

Re: FWIW, port 465 gets standards-track blessing from RFC8314

By Harald Koch at 02/12/2018 - 21:28

Compatability with the clients that only implement one?

Re: FWIW, port 465 gets standards-track blessing from RFC8314

By LuKreme at 02/12/2018 - 22:05

On 2018-02-12 (18:28 MST), Harald Koch < ... at pobox dot com> wrote:
Are there any? It's been a long time since I saw someone using an old enough Outlook to require 465.

Re: FWIW, port 465 gets standards-track blessing from RFC8314

By Viktor Dukhovni at 02/12/2018 - 23:30

There's not much gain. If both the client and the server are misconfigured
on port 587, a client might send passwords and message content in the clear.
If at least one insists on TLS, and the server does not offer SASL auth prior
to TLS, there's no compelling reason for port 465. Hence the case for 465 is
not especially strong, but it now has "official" IETF blessing.

Nobody in the working group had strong enough objections to argue against
the authors' desire to make all the MUA protocols (IMAP, POP and submission)
look alike and support "implicit TLS". With MUAs mostly doing implicit TLS
for IMAP and POP, doing the same for SMTP submission looks better on paper.

So make your judgements about what this means to you. The main idea is to
require TLS, whether it is "implicit" or "STARTTLS" is rather secondary.

Re: FWIW, port 465 gets standards-track blessing from RFC8314

By Peter at 02/12/2018 - 23:58

On 13/02/18 16:30, Viktor Dukhovni wrote:
There is one case that I can think of. Older clients (Thunderbird comes
to mind) offered an opportunistic STARTTLS setting, so that if the
server offered TLS it would connect with TLS but if not it would
continue to connect via plain text. Such a client in this setting could
be subject to a MITM attack even if the server is configured to only
allow STARTTLS connections. The MITM would simply connect to the server
via STARTTLS but not offer the client the option.

Note that newer versions of Thunderbird (I believe for several years
now) do not offer this opportunistic STARTTLS setting, so if you set it
to connect via STARTTLS it will simply not work at all if STARTTLS is
not offered, thereby mitigating this attack angle. Also setting an
older client to require encryption would mitigate it as well.

This, I believe would be the strongest reason to prefer SMTPS
connections, but it only applies to older clients that are not well
configured.

Peter

Re: FWIW, port 465 gets standards-track blessing from RFC8314

By Viktor Dukhovni at 02/13/2018 - 00:03

Sorry, you're right, the client has to enforce TLS, whether implicit
or not. Some clients try multiple ports and multiple operating modes,
so might also try port 25 in the clear, 465 with TLS and 587 with or
without STARTTLS. Such clients are subject to MiTM. The server
should also insist on TLS, to better train its clients, but the
primary burden to ensure security is on the client.

Re: FWIW, port 465 gets standards-track blessing from RFC8314

By Peter at 02/13/2018 - 00:39

On 13/02/18 17:03, Viktor Dukhovni wrote:
Right and here you're referring to the auto-configuration feature on
most modern clients. If a server is correctly configured to not allow
plain text authentication in any means but a client's auto-configure
picks up a working auth on a plain text connection then it would seem to
me that a MITM is active. This would become apparent as soon as the
plain text connection is attempted when the MITM is no longer there,
though as the auto-configured settings would be saved.

The main difference between this and the previously-mentioned
opportunistic STARTTLS that older clients offer is that those older
clients will fall back to plain text at any given time, not just during
auto-configuration. This makes the attack vector more dangerous, imo
because it would not become apparent to the user that anything is wrong
when this happens or when the MITM goes away, it would all appear to
just work normally the entire time.

Peter

Re: FWIW, port 465 gets standards-track blessing from RFC8314

By Kevin A. McGrail at 02/12/2018 - 22:16

On 2/12/2018 9:05 PM, @lbutlr wrote:
We support all the ports.  Stretching for a benefit, the only one I can
see is that it's SSL from end to end without one bit of clear text.  I
would suppose that would make it less likely to hijack.  I'll admit it's
a stretch.

Regards,

kAM

Re: FWIW, port 465 gets standards-track blessing

By Harald Koch at 02/11/2018 - 21:26

Is this change in long-standing opinion of the IETF only because existing
implementations so often ignore STARTTLS, or is there actually a security
issue with STARTTLS (instead of implicit TLS)?

Re: FWIW, port 465 gets standards-track blessing

By Matus UHLAR - f... at 02/12/2018 - 14:21

On 11.02.18 20:26, Harald Koch wrote:
I guess it's about firewalls - you can run service without TLS on 587
unnoticed (e.g. autnentication accepted without it).
you can't on 465 (implicit TLS fails)

Re: FWIW, port 465 gets standards-track blessing

By Viktor Dukhovni at 02/11/2018 - 22:04

There is no issue with STARTTLS when it is enforced by the client.
Indeed it gives the server an opportunity to evaluate the client
IP and respond appropriately in the clear, without having to first
perform a TLS handshake.

STARTTLS is just fine, especially on port 25, but is also fine
on port 587. We might now see more use of port 465, or the
status quo may continue largely unchanged.