On Tue 08/Jan/2019 19:43:25 +0100 Ted Lemon wrote:
On Jan 8, 2019, at 12:23 PM, valdis(_dot_)kletnieks(_at_)vt(_dot_)edu wrote:
Hint: If starttls is subject to a downgrade attack, what prevents the same
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.
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?
ietf-smtp mailing list