Re: [Imap-protocol] STARTTLS after PREAUTH

Lyndon Nerenberg <[email protected]> Tue, 18 Mar 2014 20:00:47 -0700
Newsgroups	gmane.mail.imap.general
Message-ID	<[email protected]>
On Mar 18, 2014, at 7:23 PM, Bron Gondwana <[email protected]> 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

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
signature.asc (application/pgp-signature, 801 B)