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.

> On Feb 11, 2018, at 8:26 PM, Harald Koch <[hidden email]> wrote:
>
> 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)?

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.

On 11.02.18 20:26, Harald Koch wrote:
>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)?

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)
--
Matus UHLAR - fantomas, [hidden email] ; http://www.fantomas.sk/Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"To Boot or not to Boot, that's the question." [WD1270 Caviar]

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

On 2018-02-11 (15:12 MST), Viktor Dukhovni <[hidden email]> wrote:
>
> 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.

Are there any? It's been a long time since I saw someone using an old enough Outlook to require 465.

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.

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

> On Feb 12, 2018, at 9:05 PM, @lbutlr <[hidden email]> wrote:
>
>> Compatability with the clients that only implement one?
>
> Are there any? It's been a long time since I saw someone using an old enough Outlook to require 465.

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

On 13/02/18 16:30, Viktor Dukhovni wrote:
> 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.

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.

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

> On Feb 12, 2018, at 10:58 PM, Peter <[hidden email]> 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.

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

On 13/02/18 17:03, Viktor Dukhovni wrote:
> 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.

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.