MBOX-Line: From dave at cridland.net  Wed Mar 19 01:52:45 2014
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Fri Jun  8 12:34:52 2018
Subject: [Imap-protocol] STARTTLS after PREAUTH
In-Reply-To: <1395195811.7439.96177201.64A35884@webmail.messagingengine.com>
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>
	<08C9B4E3-B0C3-40B3-AF7A-1B29FA09A0C9@orthanc.ca>
	<1395195811.7439.96177201.64A35884@webmail.messagingengine.com>
Message-ID: <CAKHUCzzu3atA=3gyVBJhNEKNy-hRM2+d0HmptkfbiKM1DQw4Hg@mail.gmail.com>

On 19 March 2014 02:23, Bron Gondwana <brong@fastmail.fm> wrote:

> I'd be interested in seeing the actual stats for which clients can be
> convinced by a MITM to give up their credentials in plaintext in their
> default configuration.  Don't give me a checkbox which requires the user to
> actively increase the security level, because that won't work.  In fact,
> don't even give the user a dialog which allows them to send the password
> insecurely, because they will.
>

Inky does a single leap-of-faith to handle unverified certificates during
its account setup phase, and won't (ever) send passwords insecurely. This
limits providers alarmingly; many "free with your internet" providers still
seem to insist on cleartext passwords and no TLS.

The leap-of-faith is needed because it performs RFC 6186 lookups, as well
as heuristic discovery, and providers do not supply verifiable SANs in this
case - that is, Inky's only reference identifiers [RFC 6125] are typically
domains like "fastmail.fm" or "gmail.com" rather than hostnames supplied
directly by the user.

In these example cases, the provider supplies RFC 6186 records
authoritatively:

;; ANSWER SECTION:
_imaps._tcp.gmail.com. 86400 IN SRV 5 0 993 imap.gmail.com.
;; ANSWER SECTION:
_imaps._tcp.fastmail.fm. 600 IN SRV 0 1 993 mail.messagingengine.com.

However trusting these requires either DNSSEC (which I'm not sure either
domain supports; Inky certainly doesn't) or for the certificates to include
an identifier for either the domain (which I don't think they do) or the
service+domain restricted identifier (via sRVNames for example).

I think a good first step to helping MUA developers rely on a valid trust
path would be to ensure that a valid trust path actually exists (whether
that's via DNSSEC or sRVName SANs). Then you're in a much better position
to denounce the client developers for how awful and slack they are. :-)

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140319/9fb46982/attachment.html>
