> Hiya, > Many snippets below...
> On 10/15/2013 07:13 PM, [email protected] 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. Actually, it's exactly the opposite: Details from the article make it very unlikely that tapping into IMAP sessions is a significant source of data here. In particular, both the article and the source material make it very clear that this is primarily about address book information and only secondarily about actual message content. As I noted previously IMAP does not carry address book information. Additionally, there's the peculiar use of the term "inbox" rather than to email messages in general. IMAP provides access to all folders, whereas protocols like ActiveSync are used specifically to notify users of the presence of new messages in their inbox. And as I noted previously, the peculiarly isolated IMAP slide at the end is not evidence of anything because we lack context. For all we know it was included as an example of a case where collection is particularly difficult. > (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. Explanations that appear to me to fit the available information a lot better than yours does. > > 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.) I doubt it, but even if such information were available it would be irrelevant to the matter at hand. Once more you're failing to take into account how email is actually deployed these days. For better or worse, email has seen a huge degree of centralization: The overwhelming majority of email now resides on a fairly small number of server farms. If your concern in protecting the accesses done by the majority of email users, those are the servers that count, not the one I have at home or the one operated by my (tiny) ISP. The state of play for those servers is actually pretty easy to quantify, and I'll do that in a followup message. > >> 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. More on this later. > 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. First of all, IMAP is a less than ideal example because if we were doing it today it would almost certainly be cast as a web service, and in that case it would simply be another thing in the https/http space. But if you ignore that little detail, I don't think you're going to like my conclusions of the lessons learned from IMAP in particular and email in general. My conclusionare that that most of the time the right things to do are: (1) Define the service on two ports, one with SSL/TLS covering the entire session and the other with no SSL/TLS option at all. (This makes the secure variant easy to deploying on connection-terminating load balancers, which I believe is one of the driving factors behind the use of port 993.) There are going to be a few cases, like protocols that inherently deal with nothing but highly sensitive data, where specifying the insecure port variant should not be done. But not many. In contrast, there are *no* cases where the secure port should be omitted. I don't care if the protocol as designed only transfers public information. Protocols have a way of being used in ways their designers did not intend. (2) Use the DNS in some way to announce which port a specific server expects connections to be on. (3) Specify client latching semantics as a means to detect downgrade attacks. (4) Think very hard and carefully about how certificate naming issues should be handled, and make sure your specification of them is both clear and complete. (5) Think very hard and carefully about allowed/required ciphersuites and specify that very clearly and completely as well. (It is unclear to me whether this can be done for various classes of protocols versus on a case by case basis.) (6) Do not design your protocol so that compliant operation depends on the use of SSL/TLS extensions or ciphersuites that aren't readily available in the various widely used crypto frameworks. And if this means there's some ugly wart in the protocol, so be it. (Note that this doesn't mean you call for implementation of the hoopy perfect forward secrecy scheme du jour, only that you can't depend on it.) That said, I think an exception needs to be made in the case of ciphersuites that employ rc4. I think rc4 is sufficiently problematic that its use needs to be discouraged even though that may make compliance difficult or even impossible in some cases. (7) Since there are going to be choices to make when deploying, document those choices and their consequences clearly. (8) The current fixed security considerations sections we currently employ are inadequate given how rapidly this stuff evolves. The IETF needs to develop a means of formally amending security considerations with additional information without having to open the entire document up for revision. (9) Keep the use of normative references for purposes of specifying security to a minimum. And if this means some repetition of material, so be it. Conspicuous by its abence on this list is any mention of anything being mandatory to use, and as few things as possible that would translate into something being mandatory to implement. This is because I think history shows that these sorts of IETF pronouncements - in the email world at least - have been about as useful as pissing into a strong wind. More generally, persuasion beats being doctrinaire hands down. Not to toot my own horn or anything, but since Internet email a la RFC 821/RFC 822 deployed we've managed to make exactly one really substantive change stick on a more or less global basis. That was MIME, and we did it without a single mandate that it be used. Instead we made it as compeling as we possibly could and we also bent over backwards to make it as easy to deploy as possible. > (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. That would be where you said: 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 as I noted above, you can't divorce them from inbox data collection nearly as easily as you seem to think. > 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)? See above. Again ignoring the fact that IMAP wouldn't be done in remotely the same way if we were doing it today, the anwer is no, we'd almost certainly still want to have an insecure variant. > >> (*) 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. On the contrary, what's damaging on day zero is having a specification for which compliance isn't practical for a significant fraction of implementors, deployers, or both. This is what happened in the case of IMAP, and the result was vendors ignored what the specifications called for and secured the protocol in their own way. (And security isn't the only example of this in IMAP.) > > 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. You claimed that there are valid arguments that the TLS ciphersuites that are MTI are too hard to deploy. AFAICT that claim is false. > > > > 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. Because given the way email actually works this may well be a case of putting bars on the barn windows while leaving the door unlocked. > > 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.) You need to reread your own original message as well as the material in the slides before making any such claim. > > 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.) You're still not answering the question, at least directly, and I really want a direct answer. More expensive for whom? The vast majority of current and likely future email users, who seem perfectly happy to use the service offerings of large ISPs and MSPs? If so, then any proposal you come up with needs to done in a way that persuades those providers that making changes to their service offerings is the right thing for them to do. Ned _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
