On 23 June 2014 21:15, Philipp Hancke <fi...@goodadvice.pages.de> wrote:
> [...] > > 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. > > I would dearly love you to disagree here. Not only because I'd rather like to be wrong, but it'd be just like the good old days - and in any case, I'd rather get the debate aired rather than raised later. In any case, I should probably note that while I'm more open to representational changes than I was, I'd still prefer something that remained beneficial if compression is used. > > 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. > > Certainly much of the improvement is down to Thijs. But we're comparing to what, 2008? > > 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". > > I think the key point isn't exactly what the trust relationship is, merely that there needs to be one. > > 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. > > Right, and there's perhaps a mitigation here. It's very definitely a minor point, though perhaps useful. Dave.
