ietf-smtp
[Top] [All Lists]

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

2019-01-09 13:38:59
No, the final scenario would be that instead of there being one way to
solve the problem, there would be two ways, and then you'd have interop
problems because some people would do it one way and some the other.   And
of course we'd have one less reserved port.  So it's not at all realistic
to be talking about it—it's not going to get consensus, because there's an
obvious technical objection to it.

On Wed, Jan 9, 2019 at 2:35 PM Alessandro Vesely <vesely(_at_)tana(_dot_)it> 
wrote:


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 <vesely(_at_)tana(_dot_)it
<mailto:vesely(_at_)tana(_dot_)it>> wrote:

    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
    <mailto:valdis(_dot_)kletnieks(_at_)vt(_dot_)edu> 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
    --






_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
<Prev in Thread] Current Thread [Next in Thread>