[...]
The converse of these - bandwidth efficient, secure/private, RTT efficient - would form our requirements.
makes sense.
I'd note a couple of changes to the server landscape might affect our thoughts here. a) As annoying as it is to me, compression seems related to a number of security attacks which are poorly understood in the XMPP community - TLS compression seems to be generally turned off these days, and XEP-0138 may or may not be sufficient to mount various attacks. In addition, scalability of servers has reached the point where a major scalability issue is in compression memory usage. So there's a strong argument that mere representational tricks might actually be more useful than they were.
I slightly disagree here. But not enough anymore to really object.
b) Security within the XMPP network has improved dramatically over the past few years in terms of authentication and encryption. In addition,
in the last year I'd say, thanks to the raised level of awareness because of the xmpp.net tool.
there are several cases where XMPP is used within closed networks with a general trust of peers much higher than is typical on the Internet. I suspect that between trusted peers we can do something useful.
right. Also, we need to define the trust level required. Which might not necessarily be defined by "has a valid certificate" but by "we have a business relationship with them so if they do bad things we're gonna punish them".
c) Metadata tracking by traffic analysis seems to be a valid threat; a suitable design would homogenise traffic to a degree, which might reduce the data one can glean from an encrypted session.
Right. The attack here is an analysis of traffic-over-time which might allow an attacker to determine if a certain user just logged in.
Anyone want to shoot down any of these subjective statements presented as fact?
no.
