MBOX-Line: From cloos at jhcloos.com  Wed Mar 19 12:04:16 2014
To: imap-protocol@u.washington.edu
From: James Cloos <cloos@jhcloos.com>
Date: Fri Jun  8 12:34:52 2018
Subject: [Imap-protocol] STARTTLS after PREAUTH
In-Reply-To: <1395187453.9897.96141249.7BE88CD8@webmail.messagingengine.com>
	(Bron Gondwana's message of "Wed, 19 Mar 2014 11:04:13 +1100")
References: <20140318141305.Horde.iyy0UP8Ostx9TojRZiFyjw1@bigworm.curecanti.org>
	<059bac1f-35eb-4f87-bd5e-e986dfb46b83@flaska.net>
	<20140318152549.Horde.0C2tXb4vwx_29xt0ZbwdEQ4@bigworm.curecanti.org>
	<1395187453.9897.96141249.7BE88CD8@webmail.messagingengine.com>
Message-ID: <m3ha6uxb5i.fsf@carbon.jhcloos.org>

>>>>> "BG" == Bron Gondwana <brong@fastmail.fm> writes:

BG> Your hypothetical MITM just strips the "LOGINDISABLED" capability
BG> response, and anything saying that the server supports TLS, and the
BG> client goes ahead and sends the credentials in cleartext.

The ietf consensus was that having every protocol which wants to use tls
require a second port number was impractical; that some mechanism was
required to support unencrypted and encrypted connections on a single port.

Clients can have OOB knowledge that tls must be used; many UIs have a
checkbox, config-file setting or the like to specify whether tls is
desired or required for a given server.  Clients configured to expect
starttls will abort if it does not work.

Servers also can require tls, even when using startls to initiate it,
for access to some or all resources.  TLS-level client authentication
probably is required to prevent a MITM unless the clients are all
configured to demand tls for said server.

Some servers (ipp servers are known to do this) also support recognizing
tls vs plaintext at the start of a session and doing the right thing.

In the specific case of imap, I'd prefer to configure servers to demand
starttls before permitting any authentication, and to inform the users
to configure their clients always to demand startls.

Perhaps with rfc 5054 support, where possible.

-JimC
--
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

