On Thu, May 27, 2010 at 17:36, Greg A. Woods <wo...@planix.com> wrote:
> This might seem odd to some for me to say, but I really don't understand
> why you're trying so vainly to be such a stickler for the so-called
> "standards" in this case.
>
> IANA's "port numbers" are more a Best Common Practice than a literal
> standard. You're free to provide whatever service you so wish to
> provide on any port you please. The published port assignments,
> especially those in the 0-1023 range, i.e. the Well Known Ports, are
> simply a guideline to help you to inter-operate with "unknown callers".
> If your users are all known to you then they will all know which port to
> use through prior arrangement. By definition one could conclude that
> all users of a service requiring authentication and authorization are in
> fact "known callers".
But it's more than just BCP for me (or you). It's a knowledge of BCP
for others as that might impact me (or you). For example, it means it
is unlikely that a reputable manufacturer will implement or deploy
(MSFT doesn't fit that for me).
> Finally, since running SMTP through SSL was previously defined and
> assigned a port number, then supporting legacy applications using this
> protocol and port number is well within the boundaries of valid use.
That can justify it ... on a "phasing it out" basis.
I did actually turn 465 on to see if it worked. It did. Then I
commented it out. So I have "phased it out".
> The only really valid reason for _not_ providing SMTP through SSL, (aka
> "ssmtp" or "smtps") on port 465 would be if you really had to support
> the newly assigned "urd" (URL Rendesvous Directory for SSM) protocol for
> _unknown_ callers also on port 465, and also on the exact same IP
> address (or perhaps through the same NAT-based firewall if for some
> stupid reason you've put your servers behind a NAT on some non-public IP
> addresses).
I disagree. If port 465 becomes regularly used for a non-standard
purpose, people will begin to use it and expect it to be there. If
later on (for example a few years later), the official use for port
465 (urd) needs to be deployed, then a conflict suddenly exists. And
it might not be noticed in the planning phase because it might be
different teams using these things. It may become necessary to
abruptly shut off SMTPS on port 465 because of that (if there's no
easy way to make these different services coexist, which is not a
known certainty ahead of time).
>> But IMAP and POP are enabled on a wrapped/tunneled SSL/TLS port (993
>> and 995), since a standard does exist (but I'm not telling anyone but
>> the other admin about it ... I'm promoting STARTTLS/STLS for
>> everything).
>
> Are you sure your soap-box is the most secure one to promote?
I'm not on a soap box. It has been for a long term practice (for me)
to stick with standards unless I have a compelling need to deviate
(and believe me, I have many times needed to do that). At this time,
there is no specific need for SMTPS that cannot be filled by
{SMTP|Submission}+STARTTLS on 25|587 ... so ... at this time, there is
no compelling need for SMTPS that would have me consider how to "go
beyond" the standards. If it were a standard port, I would have fired
it up just to see if it needed to be used. What I did instead is
configured it as commented out, and will address any complaints
when/if they arrive (none to date ... 2 days into activation).
> The only real reason why SMTPS was "deprecated" was solely because of
> politics. There was never any technical reason to deprecate SMTPS. It
> was done as a result of someone having the fool-headed idea to think
> that since it is _possible_ to initiate TLS from within the SMTP
> transaction, then that should be the _only_ way to do it.
I'm not disagreeing with this. I think there should be an SMTPS.
> Note that the original RFC 2487 even goes so far to suggest that
> STARTTLS is less secure than SMTPS by noting an obvious MitM attack (and
> suggesting only a relatively ludicrous work-around). That RFC's author
> gave the following contradictory excuse to IANA via e-mail in order to
> cause the unilateral deprecation of SMTPS: "The email community has
> reached rough concensus that widespread use of such a port will be
> harmful to the performance, interoperability and security of SMTP."
Correct me if I am wrong (as I have heard this only 2nd hand), but my
understanding is that the intended use of SMTPS included MX purposes
(albeit wrapped in TLS).
> Note there are even further MitM weaknesses in the original STARTTLS
> protocol as well, all of which are avoided entirely by SMTPS.
> Indeed, SMTPS threatens the success of STARTTLS because it is more
> secure than using STARTTLS.
I don't disagree. If you need more people to champion the cause to
bring back SMTPS, let me know.
> So, one must ask one's self if STARTTLS was truly the best option for
> SMTP, when why was it not so for every other protocol that could have
> been similarly extended from within, including HTTP, IMAP, NNTP, FTP,
> TELNET, IRC, and so on? The whole idea of trying to support TLS as an
> add-on or extension to an existing protocol and to do so by using an
> "optional" in-band request, is entirely antithetical to the ideal of
> using TLS to protect the _entire_ encapsulated protocol.
Perhaps (I'm speculating), the nature of the protocols (including a
_narrow_ view of SMTP) as seen by some suggested that SMTP didn't need
the level of authentication the others did. I don't agree, but just
trying to see how the process might have come to the conclusion it
did. I was never involved in that process, even as an observer (I
wish I had been).
> Finally remember that the deprecation of SMTPS was never done officially
> or via any published standard. It was done simply by fiat when Paul
> Hoffman asked IANA on his own to deprecate SMTPS prior to the final
> publication of his STARTTLS RFC 2487. The language suggesting the
> deprecation of SMTPS and reassignment of port 465 was then removed from
> the STARTTLS draft and there was no opportunity for further discussion
> through the RFC process.
There are a number of unassigned ports still in the range less than
1024. Do you feel it is worth the cause to bring back SMTPS at least
on another port number? I'm curious why it is that port 465 got
assigned to another service rather than one of the still unassigned
ports?
FYI, I do run SSH on various unassigned ports. That's because I don't
want the log floods I'd get if I had SSH facing the wild on port 22
(I've had on a couple days over a million dictionary attempts to root,
all unsuccessful, but occupying 99% of the log file space).
> Politics.
Yes. And I hate it. But I have to live with it and work around it.
