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

[Alessandro Vesely <[e-mail]>]

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 <[e-mail]
> <mailto:[e-mail]>> wrote:
> 
>     On Tue 08/Jan/2019 19:43:25 +0100 Ted Lemon wrote:
>     > On Jan 8, 2019, at 12:23 PM, [e-mail]
>     <mailto:[e-mail]> wrote:
>     >> Hint: If starttls is subject to a downgrade attack, what prevents the
>     same attack
>     >> 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 <http://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
>     -- 
> 
> 
> 
> 
>