> Following up on my own point - not stylish but I think
> in this case justified:-)
> On 10/15/2013 12:41 AM, Stephen Farrell wrote:
> > I don't
> > see why we shouldn't be equally comfortable in saying "don't
> > send cleartext" - *if* that's an IETF consensus position - as
> > we have seen sending cleartext is also just broken when one
> > consideres pervasive monitoring.
> I guess this Washington Post story [1] that I saw this
> morning would appear to provide a relevant example.
> In that case, I would argue that the fact that cleartext
> IMAP provides interop and is successful does imply that
> some services somewhere will use that for large populations
> that will inevitably (as we now know) be subject to
> pervasive monitoring.
What is this "cleartext IMAP" of which you speak? A quick check of some of the
major US MSPs shows that Gmail, Hotmail, and Apple all require SSL/TLS for
IMAP. And AOL definitely offers SSL/TLS support, but I can't tell if they
require it or not.
Now, it seems to me like I'm missing one ... it's on the tip of my tongue ...
oh yeah, that would be Yahoo, the only vendor actually mentioned by name in the
Powerpoint slides the Washington Post story you cite is based on. But lo and
behold, they also require SSL for all IMAP access!
I haven't bothered to survey ISPs (although I will note that Verizon and
several others only offers POP, not IMAP, and yes, they do offer SSL with
that), but my sense is most of them support SSL/TLS and many even require it.
But don't for a moment think this is due to anyone caring deeply about privacy.
This is about support costs, specifically, the costs that accrue when someone's
account password is compromised, as it easily can be when using any of the
email protocols from, say, a wireless hotspot. SSL/TLS covering an AUTH
PLAIN/LOGIN exchange is the method of choice for addressing this problem, and
you end up getting SSL/TLS for the rest of the session for free when you do
that.
And before the IETF spends any time patting itself on the back here, I'll also
point out that almost all secure IMAP is imaps on port 993. IETF specifications
call for STARTTLS on the regular IMAP port (143). I also doubt that the
supported ciphersuites conforms all that well to IETF guidelines.
> When the numbers involved ("500,000 buddylists and
> inboxes" collected on a "representative day" for just
> one agency) are at that scale, then it seems to me that
> one can fairly describe that as a failure in protocol
> design and not solely as a bad deployment choice.
And again I have to ask: What is the "protocol design failure" of which you
speak? I'm especially interested in the one the IETF has made that exposes
buddy lists and address books.
In case you weren't aware, IMAP does not handle address book information or
buddy lists. It's just not part of the protocol, unless you do something quite
outre like storing your address book as a special message in a special folder.
The IETF protocol that does do part of this is carddav, but it's a relative
newcomer on the scene, and while many MSPs, including Yahoo, support it, I
see no indication that it's involved here.
Rather, this all looks to me like it has a lot more to do with web access
to mail and IM, to the point where I'm skeptical that access to cleartext
IMAP is a significant factor. (There is a slide at the end about IMAP,
but it's oddly disconnected from the rest of the presentation, and seems
like something added as an afterthought.)
Something else not mentioned on the slides is ActiveSync. AFAIK ActiveSync is
the biggest player in the address book and calendar access protocol space right
now. And there may well be security issues in it. But since it's a Microsoft
creation, it's going to be tough for the IETF to do anything about any problems
it has.
> With the 20-20 hindsight afforded, if IMAP were a new
> protocol, would we be correct to only have TLS as MTI as
> we currently do [2] or would the Internet be better
> if we *only* had port 993 and had TLS as MTU perhaps
> with anon DH or something (*) like that?
No, what 20-20 hindsight actually reveals is that when you fail to respond to
market needs, in particular the needs of mobile devices, in a timely and
appropriate way, alternatives to your protocols crop up that you have no
control over. And when those alternatives have security issues there's not all
that much you can do about it.
> The latter approach is certainly now far more likely to
> be tractable than it was in 2003 (when RFC3501 was done).
> Maybe its time we do that.
> Cheers,
> S.
> (*) Yes, there's a bit of arm-waving there since one
> can validly argue that the TLS ciphersuite that's MTI
> for 3501 is still just a bit too hard to deploy as
> one is supposed to get a server cert that the UA can
> verify, which implies some management overhead. So
> something slightly more easily deployed (and hence
> not quite 3501) might really be needed. But *how* to
> do MTU stuff could be a protocol-specific debate to
> have after we concluded we had consensus for
> more-than-MTI in some form. (Which we don't, today.)
> But of course, a new IMAP security BCP doesn't have
> to wait either (hint, hint:-)
... And that's a strawman. I've not heard and provider of any size make such an
argument in many, many, many years. The fact of the matter is that secure IMAP
*is* widely and successfully deployed, albeit in a way that the IETF did not
intend and in spite of the fact that the IETF did bugger-all to make it easy to
do. And since only yesterday I was listening to a presentation that among other
things covered the specifics of how a provider with 10s of millions of users
handles this particular problem, I can state with some authority that the costs
aren't that big a deal.
But if you really think it's worth spending the time to make IMAP security even
better, that's fine with me. But the work needs to be based on what's in play
in the real world, which seems markedly at odds with what you imagine is out
there. It also needs to be informed by what's actually possible given real
world constraints, e.g., what ciphersuites are actually offered by the SSL/TLS
libraries in common use. (I've heard it mooted that support for anon-DH in
particular is likely to be dropped from some of them.) And finally,
expectations as to what this will actually accomoplish in terms of thwaring
pervasive surveilance need to be lowered pretty dramatically.
But more generally - and I'm afraid I'm going to be a bit unkind here - there's
way too much yacketing about non-issues and completely impractical
non-solutions going on here, at least when it comes to securing the
bulk of present-day email.
So I'm once again going to ask, "What's the goal here?". If the goal is to make
the email of select group of cognescenti more secure that's one thing. It's
quite another to talk seriously about improving email security for everyone
else.
If we're going to do the latter, I'm afraid that needs to start with a better
understanding of what present-day email service actually looks like and where
market trends are pushing it.
Ned
_______________________________________________
perpass mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/perpass
