> > 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.
> So you're interpreting "inbox" to mean address book. To be
> honest, I'm not convinced by that.
Of course I'm not interpreting it that way. Inbox has a very specific
and well defined meaning in email - the place where messages are delivered
to the user by default - and I'm using that definition.
> That's not how I read it - I do interpret inbox to mean
> inbox, primarily mail accessed via imap or webmail.
Of course that is what it means. But 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.
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.
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.
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. 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.
> 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.
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:
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. 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.
> >
> >>> 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
