On 7/23/20 11:43 AM, John Levine wrote:
My reading is thay the above text clarifies to prefer 465 over 587.
Some of us disagree about how well this advice matches reality. See
you at the BOF.
What does it even mean to say that this does or does not match "reality"?
The advice is to use ports that do TLS on connect (465, 993, 995)
rather than ones that connect and then use a command to upgrade (587,
110, 143) on the theory that a bad guy might do STARTTLS stripping on
the latter. I think it is reasonable to assume that any adversary that
knows how to mess with STARTTLS packets also knows how to do port
blocking, and if one port doesn't work MUAs will try the other, so it
I also observer that MUAs all offer the option of doing it either way
when you set them up, and remember that configuration for subsequent
connections. More useful advice would be to configure a TLS connection
of either type at setup time, and if that configuration later stops
working, alert the user rather than silently working around it.
1. Let me address the latter point first.
The draft that became RFC8314 was intended to recommend exactly that for
user agents: establish parameters for a secure connection when the
connection is set up, remember those parameters for subsequent
connections, and fail if the pre-established requirements for connection
setup were not met. For example, section 5 repeatedly discusses
recommendations for "establishing new configurations" and "account setup".
However, as I read the document now, this is certainly not stated as
clearly as I would like. I'm thinking that some of the text in earlier
drafts that specified user agent requirements, was removed in a late
edit in an attempt to make the document less cumbersome to read.
2. Regarding ports: 8314 doesn't make recommendations in terms of which
ports to use, but rather to use Implicit TLS in preference to
STARTTLS. (This may seem like a subtle point, but in practice a server
operator can operate a service using Implicit TLS over any port that he
or she wishes. There is no protocol requirement to use the IANA port
assignments.) "Implicit TLS" simply means to configure a client and
server to negotiate the TLS connection immediately after TCP open, on
whichever port they are both configured to use.
The preference for Implicit TLS over STARTTLS is based on the assumption
that it's harder for an attacker to hijack a Implicit TLS connection, or
force a downgrade of such a connection to cleartext, than it is for an
attacker to force a downgrade of a connection using STARTTLS to use
cleartext. Neither a client that is configured to use Implicit TLS nor
a client that is configured to use STARTTLS should ever fail over to
cleartext, and I think 8314 is clear enough about that.
But, as stated above, 8314 was intended to recommend that an MUA
determine the requirements of an account's configuration when an account
is set up, NOT to do this on a per-connection basis. If the client is
pre-configured to use Implicit TLS on some port when talking to the
server, and for whatever reason that connection setup fails (e.g. TCP
open fails, TLS negotiation fails, certificate validation fails),
something is wrong and the client should abandon that attempt to
establish the connection.
The client is NOT expected to fail-over to STARTTLS on a different
port. The whole point of establishing the connection in advance and
preferring Implicit TLS is to minimize the potential for downgrade attacks.
ietf-smtp mailing list