Hiya,
Many snippets below...
On 10/15/2013 07:13 PM, ned+perp...@mrochek.com wrote:
>> 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?
I guess that's a fair comment - we don't know that they're
able gather to inbox data via IMAP due to it being sent in
clear, however that seems like a reasonable guess based
on the newspaper story which says that collection is done
by telcos that are "overseas" and assuming that TLS is not
busted for these services. (Even were TLS busted for those
services though, I don't think that changes so much of the
analysis *if* one can separately mitigate whatever's gone
wrong with those TLS deployments.)
But yes, that's guessing and we need to keep that in mind
and there could well be alternative explanations.
> 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.
Is there publicly available information about the deployment of IMAP
in terms of how many servers/services allow or disallow cleartext,
STARTTLS or 993? (To expose my ignorance, yes, I did assume that many
services still allow IMAP over 143 without STARTTLS in addition to
993.)
> 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.
Sure.
> 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).
Rught. An important point I think.
> I also doubt that the
> supported ciphersuites conforms all that well to IETF guidelines.
Again, any information on what's available & what's used (if its
basically the same set of libraries as used for HTTP that's
probably known).
>
>> 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?
Basically, having three flavours of IMAP (clear, STARTTLS and 993)
where one that just mandated use of TLS could arguably be simpler
and more secure. And note - I'm not saying this should've been
done years ago, I'm asking if in a similar situation today we
ought go for the one-with-security or the 3-flavoured approach.
(Ignoring the rest of the message and just dealing with that
would be fine from my pov if that helps.)
> I'm especially interested in the one the IETF has made that exposes
> buddy lists and address books.
Address books? When did I mention those? I don't believe I did and
if I did then that was in error. The buddylists things in the slides
are also presumably not IMAP related.
>
> 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.
Yeah, address books would be different, but again I don't
believe I even used that term in this discussion.
>
>> 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.
Hmmm. That may be true. But I don't think you answered
the question, except with the first word and then I'm
not sure if that's an answer or disagreeing with the
question.
Lemme try another way: if IMAP were a brand new protocol
today and given today's kit and network and what we've
learned, would we argue to define both an insecure and
a secure (but maybe not much used) variant or would we
be better off only defining one version that builds in
whatever we think is the right set of securiy features
and ensures that those are used (by not having the
option to not use 'em)?
>
>> 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.
Yes - I think that supports my argument - the existence of a
"pretend" security variant at day zero is damaging so we should
ask whether we ought just make the security mandatory to use
and end up with one version.
> 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.
I don't get what you mean there.
>
> 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.
Disagree. But that (I hope) is because you misinterpreted what
I'm asking/saying.
> 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.
Yeah. There're similar issues for TLS in general.
> (I've heard it mooted that support for anon-DH in
> particular is likely to be dropped from some of them.)
That's fair. I did acknowledge arm-waving though.
> And finally,
> expectations as to what this will actually accomoplish in terms of thwaring
> pervasive surveilance need to be lowered pretty dramatically.
Why? And even if so, it may be worth doing as proection
against other bad actors.
> 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.
I think that's not unkind but is unfair. (Given that I think
you yacketed about address books above for example.)
> 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.
Better understanding is always good and the main goal here (at least
mine) is to make pervasive monitoring more expensive to the extent
technically feasible. Personally, I think there are things about IMAP
that could be impoved but I'm very skeptical that we can "solve" the
problem for mail in general. (Some others on this list are more
optimistic.)
S.
>
> Ned
> _______________________________________________
> perpass mailing list
> perpass@ietf.org
> https://www.ietf.org/mailman/listinfo/perpass
>
>
_______________________________________________
perpass mailing list
perpass@ietf.org
https://www.ietf.org/mailman/listinfo/perpass
