MBOX-Line: From lyndon at orthanc.ca  Tue Mar 18 20:00:47 2014
To: imap-protocol@u.washington.edu
From: Lyndon Nerenberg <lyndon@orthanc.ca>
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: <0327E34F-DD13-4350-A16F-FE621E029FEB@orthanc.ca>


On Mar 18, 2014, at 7:23 PM, Bron Gondwana <brong@fastmail.fm> wrote:

> So why is 993 deprecated rather than STARTTLS deprecated now?  STARTTLS is _still_ a bad idea.

That seemed to be a political argument within disparate IETF WGs.  Begrudgingly I would nominate Chris to talk about that history, as I recall he was involved (or argued) during the period.  But I also know many people want to forget about it.  I just ignored the whole thing due to the in-fighting.

Okay, not completely.  I was discouraging against SSL on 993 for one main reason:

If SSL is proven broken, where do we go?  Another port for another encryption layer?  How does that scale?

And I think that was the crux of the overall IETF argument against allocating dedicated ports to dedicated SSL versions of the existing protocols.  SRV was supposed to mitigate against that, but SRV hasn't taken over the protocol developer community.

> We don't need a wayback machine to fix the future.

But we need it to fix the past, and that's what you are complaining about.

> Sadly, they're still out there - which is why FastMail doesn't allow port 143 at all.  Port 993 appears to be working in the real world[tm].

No doubt.  Almost every IMAP client I stumble across today supports it.  But what happens when TLS is broken in a way that requires divorcing from any of the previous instantiations?  It will happen.  Do we roll off to yet another port number for the new version?  We have much fewer than 65535 cracks at that cat.  And what about all the existing clients that still expect to speak to port 993 TLS <=1.2?

> 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.

Stop being a tease ? you know they all will (some require a little more foreplay than others).

But how do you propose to solve this in an everlasting manner?  Imagine how embarrassed you will be when your grandchildren break your perfect encryption system on their laptops.  From the womb.

--lyndon


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 817 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20140318/aa1fef39/attachment.sig>
