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

Keith Moore <> Mon, 27 July 2020 03:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE70C3A164D for <>; Sun, 26 Jul 2020 20:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oUPfrfoSPsYn for <>; Sun, 26 Jul 2020 20:21:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 494FB3A1645 for <>; Sun, 26 Jul 2020 20:21:00 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 50E5F5C00B3 for <>; Sun, 26 Jul 2020 23:21:00 -0400 (EDT)
Received: from mailfrontend1 ([]) by compute4.internal (MEProxy); Sun, 26 Jul 2020 23:21:00 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=9Y64Rztai33d3HVA1vR/LLz7gnM+ImJLJFFhw+R40 N4=; b=p/ugxknIWqGl1DNr+OR3pIcL7UreFz1hhQiGL+Y2Pk2oKwTAuQN1ed7T/ kV9q7S/TgqyQcF89ySvF3gK8dQq02vsVWeBngx3FeAkBlb6o+o8lt4ggSPLH0+fP h5ATrH7Hzfh30rJk/bG/k8SWJit2m5qG9tkcNFvTjCRhbpP5ux+T5MAkw5BHCnYG RMsddRMI4FHbEQN4G2hZ6etaxPfMCvCoP2kcfNqJhQK/4M1dUoPUYWeGScVxInnm 5SPRGB9AQxeIrRZ6dkfnOlye/pq4qawGNFnus2ho/pfPq+y8tV1vQX7vff501hlJ pUNjPrg8zkRUoiN7J6enAnWtDrPZQ==
X-ME-Sender: <xms:G0geX9tELdo583MW25v9WotcBJywXOFvu6r9IJUC7NKlQUH6OVG3mg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrheelgdduiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekre dttdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrfgrthhtvghrnhephefhuedtheefgf efgffhkeehgfeugfeiudeugeejkeefleelueeiffetfeeuudeunecukfhppedutdekrddv vddurddukedtrdduheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:HEgeX2cv_Txhcszq2dbhDbuOBx4yRQMMz7mZ8hVw83o6bsPcw2eRBg> <xmx:HEgeXwwRuGxNkzhf4BZpm9BX4c_TupiT5UT5lmQZMjZY_YgeXeNE2Q> <xmx:HEgeX0N2ow2EzLAUuwKehJ3KEhzZXE2IwgToC2adxmabV_pkVNxLlw> <xmx:HEgeX-etCnwBm2xGfHFtO7whuWMLfEEFO6UMNKYQvqVPAN3EgvBKHg>
Received: from [] ( []) by (Postfix) with ESMTPA id C7D74328005E for <>; Sun, 26 Jul 2020 23:20:59 -0400 (EDT)
References: <20200723154322.9C29B1D694AC@ary.qy>
From: Keith Moore <>
Message-ID: <>
Date: Sun, 26 Jul 2020 23:20:58 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <20200723154322.9C29B1D694AC@ary.qy>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <>
Subject: Re: [ietf-smtp] Proposed agenda for EMAILCORE BOF
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 27 Jul 2020 03:21:04 -0000

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.