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

[Keith Moore <[e-mail]>]

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