Hi, On 10/17/2013 11:11 PM, [email protected] wrote: > ...I'm starting to wonder whether or not > we're reading the same article. There's only one reference to acquisition > of mail message content in the one I'm reading, which says: > > Each day, the presentation said, the NSA collects contacts from an estimated > 500,000 buddy lists on live-chat services as well as from the inbox displays > of Web-based e-mail accounts. > > I'm not going to bother quoting the correponding material on the actual slides > because I'd have to retype it, but it absolutely backs up this paragraph.
The slides eventually linked to are at [1], slide 4 bullet 2 is the main one I think but you're right that the first bullet says webmail. My assumption is that they use every possible way they can, whether that's webmail or IMAP or IM or whatever goes by in clear or more probably some combination. [1] http://s3.documentcloud.org/documents/804763/a-sso-content-optimization-detailed-redacted.pdf > > Clearly the inbox information is coming from web mail. And the way modern web > mail works is a big wad of Javascript gets downloaded to the browser, which > then communicates with the back end server by exchanging JSON, XML, HTML, > whatever with a back end server. The client state, to the extent there is any, > is jointly maintained by the front and back ends. Thanks for web-mail-101 lesson;-) > The web mail server (which may consist of multiple server layers, proxies, > caches, separate authentication servers, and who knows what else) then talks > to > the actual message store. In many cases this is done in a proprietary fashion. > And if IMAP is used, those IMAP connections are happening within the data > center, not on the open Internet. Even if the connections travel from > one data center to another (the use-case for that would be shared folder > access, which by definition is not going to be your inbox), that's going > to be done on a private network, if for no other reason than to avoid timeout > issues. Sure. But with 4.7M listeners on port 143 (see my earlier mail) it would be credible too to get a bunch of those via installations that don't have a working starttls setup. Mind you the above speculations aren't really decideable so its probably not worth our time to quibble further on it. > > And as I noted before, ActiveSync may play a role here, although I'm not > familiar enough with the use cases for it to be sure. > >>> 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. > >> I agree it stands out from the others and is hard to interpret. >> I don't think inbox is hard to intepret at all though. > > It isn't. But you appear to have not considered the context in which it was > used. > >>> 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. > >> I don't dislike 'em actually. Most seem reasonable. > >>> 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.) > >> That's the bit I'm questioning. I figure that if we could do >> just the secure one, then we'd be done and that'd be a better >> approach than having two. I also think that if we muck up and >> do a pretend job on security then we end up with 3: plain, >> pretend-secure and eventually-fixed-secure. That's happened >> with more than IMAP. > > It's not what happened with IMAP. I didn't say the above was a blow-by-blow description of how we ended up with IMAP. But we did end up with 3 flavours as described. > We specified one mechanism with real > security, but included enough weasel words that engaging that security was not > required. But the mechanism we specified failed to meet deployability > requirements in the real world, and as a result a plurality if not an actual > majority of what actually deployed was a secure mechanism we did not specify. That's consistent with what I said above. >> I don't know if only doing the secure one in an IETF context >> is at all likely though. History would seem to show that its >> not. OTOH, it is true that doing the secure versions is much >> better understood now and much more practical than it was a >> decade ago, so I think its worth exploring. > > And the reason it is not is that there are compelling reasons to provide > the variant without security. > >>> 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. > >> Why? Serious question. > > Because of things like usage inside of data centers, where all the connections > are either protected physically or by encryption at a different layer. Indeed, > there are use cases where security auditing mandates that SSL/TLS *not* be > used. That's not inconsistent with the default being to include and turn on security from day 1. Things can also be turned off for scenarios such as the above, so I still don't see a need to have specs that only cover the insecure/plain version of things like IMAP. My point is that if we took that approach then we'd be far less likely to screw up the security bits, for performance, deployment or "too much" security reasons or whatever reason your undoubted experience tells you is most common. > Now, of course you can argue that this is some sort of private use case that > doesn't warrant coverage in the relevant standards. But I'm here to tell you > that this sort of handwaving is increasingly being seen for what it really is: You put words in my mouth and then accuse me of handwaving? That makes it hard to have a discussion on what is I think an important topic. (How to screw up less with how we define security for our protocols.) It'd be better maybe to tone that kind of thing down a bit. > A refusal to come to grips with how applications are implemented and deployed > at very large scale. And it doesn't help when we also botch the secure variant > we do specify. > >>>> 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.) > >> I agree that that happened and was damaging. I don't thinks its >> at all contrary to what I said. > > I don't know what "contrary" means in this context. You said "on the contrary" - I don't think we're disagreeing much. > That said, it is my > position, based on decades of dealing with the major players in this space, > is that what you are proposing will at best be ignored and at worst be even > more damaging. I'm getting the impression you think I'm proposing something I'm not, but its quite hard to tell really. S. > >>> >>>>> 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. > >> I do think that the PKI parts are too hard to deploy. Not for >> the larger MSPs, but it could be a good bit easier. Or maybe >> you're the one person in the universe who thinks that deploying >> PKI is a doddle:-) > > The way the PKI part of this plays is that there's an initial pain point > getting it going and, for a large data center, automating certification > generation and distribution. But this is a one time cost, and not a > substantial > one. > > More generally, you don't seem to grasp the way a setup with 10s of millions > of > accounts with services scattered across hundreds, thousands, or even tens of > thousands of hosts has to operate. In such a world the automation of > certificate generation and distribution is an insignificant detail buried > inside of a vast amount of other automatic configuration processig. > > Ned > _______________________________________________ > perpass mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/perpass > > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
