ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Proposed agenda for EMAILCORE BOF

2020-07-26 22:21:18
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
doesn't help.

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.

Keith


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp