Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Carlo v. Loesch]

In the last post I actually forgot to comment on the post I most agree with...

On 11/19/2013 01:26 AM, Thijs Alkemade wrote:
> Federating over hidden services requires some extra work, but it’s not that
> hard. I’ve written a Prosody module for it, which can be found at [1]. Some
> more background at [2].

That's excellent news. Now the XSF should focus on migrating XMPP away
from DNS/X.509 federation into the Tor network. There may be scalability
issues involved however.

> Tor already offers forward secrecy, if I remember correctly it uses TLS with
> EDH. Unless you want to assert a clearnet identity, I don't see the added
> benefit of using TLS when accessing a hidden service.

The key sizes aren't extremily high, that's why Jacob Appelbaum usually
recommends to use an extra end-to-end encryption layer. He likes to use
https over .onion and PGP over Pond. I personally think key size isn't
the most important criterion - moving into Tor is a huge improvement
for privacy.

> For s2s, you have the same solution as with most servers currently: dialback.
> .onion addresses being cryptographically verified makes this actually secure
> in this case. This would work even when federating between hidden services and
> normal XMPP servers (although the normal server needs Tor access, of course,
> and the hidden service must keep in mind to always use Tor to dialback).

It's tricky because outside servers get connections from Tor exit nodes
so they have to fully trust what the cryptography tells them and totally
ignore where the packets are coming from.


On Tue, Nov 19, 2013 at 06:14:23PM -0700, Jeremie Miller wrote:
> Carlo, I happen to working very hard on something that sounds almost
> exactly like what you're describing called telehash for many of the reasons
> you express, and once it's a little more functional I have a strong desire
> to demonstrate it working very compatibly/naturally with XMPP, of course :)

I am familiar with TeleHash of course and wrote my $0.02 about it two
years ago in the usual place:  http://about.psyc.eu/Telehash  - I'm
glad you added encryption to the equation, but I still think you should

- consider protecting transaction data (by using Tor for example)
- that also liberates you from having to write your own NAT traversal
- use a more advanced DHT implementation (check out GNS)
- consider using a more efficient wire protocol
  (see http://lib.psyc.eu/bench/ for the performance shoot-out)
- you may also want to consider many-to-many use case scenarios
  which you are currently not addressing

If you don't intent to provide protection for transaction data and
thus for the social graph, then there is nothing wrong with gatewaying
to XMPP since the privacy assumptions are the same. I personally think
systems that do not protect the social graph have this summer been
proven to be bad for humanity - that's why I gave up on PSYC federation.
But everyone has his or her own conscience.


On 11/19/2013 05:29 PM, Andreas Kuckartz wrote:
> Carlo v. Loesch:
>> but if you ask me I would say because if
>> taken in on a global scale, social graph data gives you enough
>> information to be a threat to liberty and democracy of entire
>> populations. I presume you can find plenty of scientific analysis,
>> ...
> 
> That is correct. Determining the social graph has for a very long time
> been one of the tools of all repressive regimes.

THEN WHY OH WHY ARE YOU BY ALL VIGOROUS MEANS LOBBYING FOR FEDERATION
AND NOT TAKING THE LOGICAL CONSEQUENCES!?!?!?

> Having followed recent discussions around #youbroketheinternet I fear
> that the second half of the sentence was not meant ironically. I
> definitely disagree with that "best intentions" statement.

I merely think it is out of scope of this mailing list to question the
actual motives behind our governments' actions. Whatever led them to
do the wrong things they did, we can take legislational and technical
measures to limit the damage. Unless of course activists are more busy
patching up broken systems rather than setting up working ones.

>> By conseguence interoperability and "open standards" are no relevant goal:
>> They were introduced in order to make companies have their proprietary 
>> technology
>> speak a common language - but since proprietary technology by design cannot 
>> be
>> reliably respectful of privacy, we must design our future communication paths
>> free of proprietary contributions.
> 
> I understand that #youbroketheinternet is not interested in
> interoperability and open standards. That is one reason why I am

No, you didn't understand it. You are reacting to it as if it was
just some folks' opinion like you have yours, but if you were
scientific in what you think and do, you should either have a good
reasoning to criticize those words or start acting on the basis of
them being a fact.

> convinced that it will be far less relevant than some people hope it
> will be.

Yes, just like Facebook is far less relevant. Faceb

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Andreas Kuckartz]

Carlo v. Loesch:
> Somebody wrote:
>>> In case others are not yet aware: #youbroketheinternet is not only
>>> explicitly opposed to federation but not even interested in
>>> interoperability with federated communication networks.
>
...
> I presume it is Mr Kuckartz writing, correct?

Yes, Mr v. Loesch, that is correct.

> If you want to talk to people on Google use whatever tools
> you want to use - don't mix it up with a system that is supposed to
> give you completely different degree of privacy - and uses completely
> different technology to achieve that - so there is no technological
> advantage in supporting XMPP or SMTP anyway. It would be an add-on
> that breaks user expectations. No good.

One expectation of users is that they can continue to communicate with
other people without much hassle. In some cases this is impossible to
implement because terms of services of some proprietary platforms do not
allow this. One reason for those ToS is to prevent alternatives from
amplifying their network effects. Alternatives which are deliberately
preventing users from communicating severely weakens network-effects
which otherwise could work in favor of new technologies.

If #youbroketheinternet is becoming somewhat successful then such
"add-ons" will be created so it would be better to plan for that now.
That #youbroketheinternet is not interested in that is a flaw in the
concept and not in the interest of users.

> But if you look at the http://youbroketheinternet.org/map you can see
> several federation technologies in the upper right corner. Why?
> Because their expertise at designing web interfaces for social
> networking is still very welcome. We just need to replace the
> networking engine underneath. Hey, it even mentions Buddycloud.

Yes, I had suggested to include buddycloud and Jitsi. But that was not
simply because of their user interface but because they are using
federated protocols and that including those projects would amplify
network effects.

> They just need to see that XMPP is not the future neither for the
> necessary privacy nor for the necessary scalability to achieve what
> they intend to achieve: be a serious competition to Facebook.

If that were the aim of buddycloud then restricting the social
connections of users to those using #youbroketheinternet would be
counter-productive and a guarantee for failure.

> No, I think it's in a wrong assumption of the federation principle,
> that you can trust your university, your company or your boyfriend
> better. Most people don't have any reason to trust anyone, so they
> pick what is likely to have the least interest in them personally -
> that's usually a large silo offering.

In companies and other organisations it is usually those organisations
deciding such questions and not the individual. And that is also true
for smaller groups such as this mailing list using SMTP.

> But history repeats itself. When the first cars were developed, 90% of
> the engineers where probably focused on refining the efficiency of
> horse carriages.

Motorized cars used the same road network as the horse carriages. People
using the new vehicles were not limited regarding the set of places they
could drive to by requiring them to use a new non-existing road network.
The roads used by both cars and horse carriages were improved and only a
long time later horse carriages were no longer allowed on many roads.

Cheers,
Andreas

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Jeremie Miller]

Carlo, I happen to working very hard on something that sounds almost
exactly like what you're describing called telehash for many of the reasons
you express, and once it's a little more functional I have a strong desire
to demonstrate it working very compatibly/naturally with XMPP, of course :)



On Tue, Nov 19, 2013 at 4:30 PM, Carlo v. Loesch wrote:

> Oh.. I didn't receive some of the messages.. probably originating
> from Andreas.. strange. Again a multi-reply to avoid clogging the
> mailing list:
>
>
> On Tue, Nov 19, 2013 at 01:27:29PM -0700, Peter Saint-Andre wrote:
> > Hi Carlo!
> > I need to spend some quality time with your long message, but I don't
> > have time for that right now. One quick point...
>
> lol! Hi Peter, was a pleasure meeting you this summer.
>
> > As you might remember, the original Jabber community was focused on
> > code but also on defining and documenting an open protocol. There were
> > no corporate interests pushing agendas (although some of the jabberd
> > developers had some support from Webb Interactive Services), just
> > coders making sure that clients and servers could interoperate.
>
> The stuff I wrote wasn't specifically addressed, especially not
> at early Jabber. I know well that it was all created with best
> intentions. I wasn't happy about the choice of a document syntax
> for a messaging protocol, but the only thing I *really* complained
> about was the lack of providing a distribution strategy for larger
> recipient groups. I was just echoing basic things any IRC developer
> knows concerning multicast, but the Jabber community didn't believe
> the problem exists. So even today it's a problem to have more than
> a hundred friends on a federated XMPP network, then try to do social
> networking with them. The more time passed, the harder it got to
> tackle the problem, because by then there were companies earning
> money by selling scalable XMPP server solutions - a federation that
> actually scales properly would be detrimental to their business.
>
> Even if this maybe isn't how it actually went, it is a reason more
> why having corporations in the mix is bad for freedom. They can have
> an interest in blocking technologies from getting better, and they
> might be getting away with it by smart rhethoric and convincing
> representatives. This time however they are putting our civil liberties
> at risk, so we need to prioritize. Companies should be *users* of the
> Internet, not *owners.* But currently they are owning the majority of us.
> Again I'm not talking about the small players on this mailing list
> working to bring some earnings back home.
>
> > I think we need three things: open source, open standards, and an open
> > community. In fact I wrote an article about it way back in 2003:
>
> Back in 2003 I probably agreed, but by now I understand what Richard
> Stallman says when he's against "open" and underlines the necessity
> of "free." I need no open source, no open standards, no open community.
> I want free software, free hardware and a free community. May sound
> similar but the political differences are actually big and the
> repercussions are being felt since June.
>
> > But these days the threat model has changed and I think we need to go
> > beyond merely "open" to "trusted". Yes, trust is a slippery concept,
> > but in my mind it's connected to things like hardware (e.g., PNRGs),
> > build processes, transparency of releases, community governance,
> > software that does what the user intends and no more, etc. This is
> > something bigger than any particular technology, so this list might
> > not be the best place to discuss it. Maybe a blog post or new
> > discussion venue is in order...
>
> You just described what #youbroketheinternet is about.
>
>
> Somebody wrote:
> >> In case others are not yet aware: #youbroketheinternet is not only
> >> explicitly opposed to federation but not even interested in
> >> interoperability with federated communication networks.
>
> This reminds me of a word that I learned on this list years ago.. "snarky"
> I presume it is Mr Kuckartz writing, correct? For some odd reason I didn't
> get this mail.
>
> Anyway - it's a question of user expectation. You can't tell your
> grandpa that this is the first software that actually implements your
> constitutional right of secrecy of correspondence.. unless you add a
> friend via XMPP that happens to have her account on Google. It's too
> complicated. If you want to talk to people on Google use whatever tools
> you want to use - don't mix it up with a system that is supposed to
> give you completely different degree of privacy - and uses completely
> different technology to achieve that - so there is no technological
> advantage in supporting XMPP or SMTP anyway. It would be an add-on that
> breaks user expectations. No good.
>
> But if you look at the http://youbroketheinternet.org/map you can see
> several federation technologies in the upper right corner. Why? Because

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Carlo v. Loesch]

Oh.. I didn't receive some of the messages.. probably originating
from Andreas.. strange. Again a multi-reply to avoid clogging the
mailing list:


On Tue, Nov 19, 2013 at 01:27:29PM -0700, Peter Saint-Andre wrote:
> Hi Carlo!
> I need to spend some quality time with your long message, but I don't
> have time for that right now. One quick point...

lol! Hi Peter, was a pleasure meeting you this summer.

> As you might remember, the original Jabber community was focused on
> code but also on defining and documenting an open protocol. There were
> no corporate interests pushing agendas (although some of the jabberd
> developers had some support from Webb Interactive Services), just
> coders making sure that clients and servers could interoperate.

The stuff I wrote wasn't specifically addressed, especially not
at early Jabber. I know well that it was all created with best
intentions. I wasn't happy about the choice of a document syntax
for a messaging protocol, but the only thing I *really* complained
about was the lack of providing a distribution strategy for larger
recipient groups. I was just echoing basic things any IRC developer
knows concerning multicast, but the Jabber community didn't believe
the problem exists. So even today it's a problem to have more than
a hundred friends on a federated XMPP network, then try to do social
networking with them. The more time passed, the harder it got to
tackle the problem, because by then there were companies earning
money by selling scalable XMPP server solutions - a federation that
actually scales properly would be detrimental to their business.

Even if this maybe isn't how it actually went, it is a reason more
why having corporations in the mix is bad for freedom. They can have
an interest in blocking technologies from getting better, and they
might be getting away with it by smart rhethoric and convincing
representatives. This time however they are putting our civil liberties
at risk, so we need to prioritize. Companies should be *users* of the
Internet, not *owners.* But currently they are owning the majority of us.
Again I'm not talking about the small players on this mailing list
working to bring some earnings back home.

> I think we need three things: open source, open standards, and an open
> community. In fact I wrote an article about it way back in 2003:

Back in 2003 I probably agreed, but by now I understand what Richard
Stallman says when he's against "open" and underlines the necessity
of "free." I need no open source, no open standards, no open community.
I want free software, free hardware and a free community. May sound
similar but the political differences are actually big and the
repercussions are being felt since June.

> But these days the threat model has changed and I think we need to go
> beyond merely "open" to "trusted". Yes, trust is a slippery concept,
> but in my mind it's connected to things like hardware (e.g., PNRGs),
> build processes, transparency of releases, community governance,
> software that does what the user intends and no more, etc. This is
> something bigger than any particular technology, so this list might
> not be the best place to discuss it. Maybe a blog post or new
> discussion venue is in order...

You just described what #youbroketheinternet is about.


Somebody wrote:
>> In case others are not yet aware: #youbroketheinternet is not only
>> explicitly opposed to federation but not even interested in
>> interoperability with federated communication networks.

This reminds me of a word that I learned on this list years ago.. "snarky"
I presume it is Mr Kuckartz writing, correct? For some odd reason I didn't
get this mail.

Anyway - it's a question of user expectation. You can't tell your
grandpa that this is the first software that actually implements your
constitutional right of secrecy of correspondence.. unless you add a
friend via XMPP that happens to have her account on Google. It's too
complicated. If you want to talk to people on Google use whatever tools
you want to use - don't mix it up with a system that is supposed to
give you completely different degree of privacy - and uses completely
different technology to achieve that - so there is no technological
advantage in supporting XMPP or SMTP anyway. It would be an add-on that
breaks user expectations. No good.

But if you look at the http://youbroketheinternet.org/map you can see
several federation technologies in the upper right corner. Why? Because
their expertise at designing web interfaces for social networking is
still very welcome. We just need to replace the networking engine
underneath. Hey, it even mentions Buddycloud. They just need to see
that XMPP is not the future neither for the necessary privacy nor for
the necessary scalability to achieve what they intend to achieve: be
a serious competition to Facebook.


On 11/19/2013 08:56 PM, Philipp Hancke wrote:
> There is the hypothesis that any federated network tends to cluster
> around a number

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Philipp Hancke]

[...]

There is the hypothesis that any federated network tends to
cluster around a number of large nodes. E.g. for XMPP this would be
gmail, jabber.org, jabber.ccc.de (applause to their efforts on
making themselves unreliable!), ...


This is true even of unfederated networks (Facebook, Twitter,
LinkedIn, Skype, the current crop of cool new mobile chat apps). My
hypothesis: human beings are herd animals and prefer to flock together
in large numbers. "Are you on hot-new-service-X?" It's much easier to
think and act that way than to strike out on your own.


Right. The benefit of federation is that _I_ can ignore the herd to some 
degree.



Interdomain federation is hard, especially delivering the same
user experience as between users on the same domain.


This is a huge factor. It's much easier to offer a consistent and
quality experience if you control both ends of the pipe


Yeah, http://vimeo.com/77257232 talks about that -- and the lack of open 
products.


I do think that webrtc gives us a good chance to move the baseline 
experience from basic IM + presence to rich federation. And heck, we've 
got some movement here ;-)


What amuses me most about webrtc is that "rich media chat" was listed as 
#6 of the six oldest ideas in chat @ 
http://antecipate.blogspot.de/2006/11/six-oldest-new-ideas-in-chat.html 
and "in-browser chat" is #2



Most people always complain about
how there's no great email client, no great IRC client, no great
Jabber client, and so on (don't even get me started on SIP clients!)
- -- with plenty of justification.


See above, as you say it's not limited to XMPP. It's a more general lack 
of accepting non-developer roles in opensource.


Peter: I really appreciate that you enjoy writing specifications!

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/18/13 3:49 PM, Carlo v. Loesch wrote:



Hi Carlo!

I need to spend some quality time with your long message, but I don't
have time for that right now. One quick point...

> By conseguence interoperability and "open standards" are no
> relevant goal: They were introduced in order to make companies have
> their proprietary technology speak a common language - but since
> proprietary technology by design cannot be reliably respectful of
> privacy, we must design our future communication paths free of
> proprietary contributions. That means that the protocol standards
> etc become a lot less important: As long as there is a well-defined
> and reviewed GNU licensed codebase, all applications can be made
> interoperable even if the protocol wasn't documented. Of course
> that is not recommendable and in fact a proper review implies
> documenting the protocol fully - but it is very distant from
> today's notion of necessity of a protocol standards body. A
> protocol can thus be driven by efficiency needs rather than lobby
> interests.

As you might remember, the original Jabber community was focused on
code but also on defining and documenting an open protocol. There were
no corporate interests pushing agendas (although some of the jabberd
developers had some support from Webb Interactive Services), just
coders making sure that clients and servers could interoperate.

I think we need three things: open source, open standards, and an open
community. In fact I wrote an article about it way back in 2003:

http://www.onlamp.com/lpt/a/3660

But these days the threat model has changed and I think we need to go
beyond merely "open" to "trusted". Yes, trust is a slippery concept,
but in my mind it's connected to things like hardware (e.g., PNRGs),
build processes, transparency of releases, community governance,
software that does what the user intends and no more, etc. This is
something bigger than any particular technology, so this list might
not be the best place to discuss it. Maybe a blog post or new
discussion venue is in order...

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSi8mxAAoJEOoGpJErxa2pGIIP/3yupgKNsZDmeGFTCpiPh9jH
jT67SKV+M/d8v0rBBoohvRY50IURnaMaoJQcPC4Y40yAASnUag9sfnhw5J1CI6W2
iilSdVd1O9j1btjDPyOiYSXfwiKWDLD1aODhgQpaZ02pYu0/8MJMVTUaxfRP+NMN
YuVRizR/avRIwNt0Wq7WEfKYqR0xQ+uFEwzxhCctTbcI400P3f6zjt2FSUDig08J
Uq0S/O9bK9FBzOo2krLqsiFx0NYdrjjpDi+RcAYPfZ6L1ShQtzBEziph8xer0olH
30O1NOZmJn6qE/kquR+L4FldgPyiXf+QmvUOpwuRpflU8CniWZpjJ82T6EoZYNTP
78nK8qL4o6cmUdFPT6YTKbgS9aIDyeZPTRt0901Ayj4EJQQLpqTTKMZcriymOWVA
PUOJ4ghvtir9AyU4MGRtBNny/UrpJ7xmNP+bmz40NtQdrGLcrZTOnx2FAoPOG4Ec
Ee0vgSfkbMryaEYSjXSi/rer8qSg39rvRAyJX50I6+IQc4K2V2WYLPkoL4qnYxs8
xfQXOVpFHAedDnY+gXy4DcIzXHR1AnQ8pe3+7+Hrp1Pizloy2oZLDCMbcW1Fg/5s
7PMbTs/E2U9s/5DLrF6/6M4pt2yi7ROrEN8rWIm23JXhSwjLcaEc8WoB1JKM0kPQ
zQEqjyKa9LMg45QglJMV
=C8IT
-END PGP SIGNATURE-

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/19/13 12:56 PM, Philipp Hancke wrote:
> [...]
>>> Having no federation at least doesn't introduce yet another 
>>> huge possibility for security problems and as long as you own
>>> the source code and aren't forced to use anybody's specific
>>> offering it is highly inadeguate to call such a software a
>>> silo.
>> 
>> In case others are not yet aware: #youbroketheinternet is not
>> only explicitly opposed to federation but not even interested in 
>> interoperability with federated communication networks.
> 
> There is the hypothesis that any federated network tends to
> cluster around a number of large nodes. E.g. for XMPP this would be
> gmail, jabber.org, jabber.ccc.de (applause to their efforts on
> making themselves unreliable!), ...

This is true even of unfederated networks (Facebook, Twitter,
LinkedIn, Skype, the current crop of cool new mobile chat apps). My
hypothesis: human beings are herd animals and prefer to flock together
in large numbers. "Are you on hot-new-service-X?" It's much easier to
think and act that way than to strike out on your own.

> Interdomain federation is hard, especially delivering the same
> user experience as between users on the same domain.

This is a huge factor. It's much easier to offer a consistent and
quality experience if you control both ends of the pipe (I'm not
saying it's easy, and I think the people who run these large,
monolithic services deserve our admiration even though I prefer a more
federated, decentralized approach). Most people always complain about
how there's no great email client, no great IRC client, no great
Jabber client, and so on (don't even get me started on SIP clients!)
- -- with plenty of justification.

Now, there's a lot that we could do to make things easier for those
who would consider deploying federated services -- servers that are
easier to run, clients that offer a better user experience, a higher
level of security, etc. One reason for the ubiquitous encryption
manifesto is that I think we owe it to our users to at least offer
better security. But easier servers and clients are part of the
picture too.

Some argue that this is all a waste of time and that it would be more
productive to start again (as Carlo says, redesign the entire stack).
I have a great deal of sympathy with that attitude, and I do think
that eventually we'll need to replace a lot of what we have now (even
at the physical and link layers, e.g., more open hardware, wireless
mesh links instead of centralized ISPs). But this is going to take a
long time, and until we have more of that built out IMHO we need to do
what we can to better secure the current generation of federated
technologies.

Let the conversation continue... :-)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSi8YqAAoJEOoGpJErxa2pRIoQAK13kxdis9J72hQ36duipHGZ
r+/BIRyvyup2wUldZ7d5VmKnXtTGdGvs/jkwRuCBQxkMwaLATG/EXnNH8h3c2THo
OtkZCDP5fTMsUC6ZRnIrjv4B/bQTKTjhkq1L41ez7Xss05JowZrEMU2jMnGk9NDt
934INBg8D2E8UyiitALXu0kkeJ8kDjXO8svj03p9U8zSmHbi0TAJGc+mV79KF3qP
BlbavkbDCTnr9AxmrSm1CvHt7owH+hyYPMVF7qOxpDlvgdtyK+B0xuWR9n42PDEM
SAqe3os8P4lG/FRBiLeYh5oAvcLgr2D7SpEdMrZsyMossrSbACq6clv/769VDpwC
dFOSWBeWRwHgRSYGCMLAq/e1UiHFI7I5vK7tjyn4ThlTn11dPT8G1K6N5R5ToP3T
N1fR8pZCtIHVR+gyg1mVROS8ojdpOYPB+bsgV4d5P5Oq8wmJ/HUd1v/LlPm9EOcw
vdEoe3R/vsDTvbDdh1cLJIq6BjYR1hlK2tABKuvUrCFJEgew5pHv2clXVGxC/E3i
MR6MCSNpbUWZvIykRVBPNzZytX2oh4H0vuRSs1WBaJGkrEYTWqLoTdV8wasmM3GK
KCDBsyTHJZEP+wgy3zRbYAoP+TAq2hHawY9pvqxNdh6lHluZRNPjK7GAEZQFXAgH
5rpZsw/xqTt5Tgat7o9D
=gyyJ
-END PGP SIGNATURE-

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Hannes Tschofenig]

Am 19.11.13 20:56, schrieb Philipp Hancke:

[...]

Having no federation at least doesn't introduce yet another
huge possibility for security problems and as long as you own the source
code and aren't forced to use anybody's specific offering it is highly
inadeguate to call such a software a silo.


In case others are not yet aware: #youbroketheinternet is not only
explicitly opposed to federation but not even interested in
interoperability with federated communication networks.


There is the hypothesis that any federated network tends to cluster
around a number of large nodes. E.g. for XMPP this would be gmail,
jabber.org, jabber.ccc.de (applause to their efforts on making
themselves unreliable!), ...
Interdomain federation is hard, especially delivering the same user
experience as between users on the same domain.

I understand the rationale. I just don't agree with it.



I don't agree with it either.

What you end up having is silos that typically consist of proprietary 
technology with limited usability for the wider Internet user community.


The benefits of XMPP are interoperability, the open standards process, 
and the large number of XMPP providers you can choose from. If you don't 
like one located in the US then pick it from some other country. If 
don't like any of them setup your own.

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Philipp Hancke]

[...]

Having no federation at least doesn't introduce yet another
huge possibility for security problems and as long as you own the source
code and aren't forced to use anybody's specific offering it is highly
inadeguate to call such a software a silo.


In case others are not yet aware: #youbroketheinternet is not only
explicitly opposed to federation but not even interested in
interoperability with federated communication networks.


There is the hypothesis that any federated network tends to cluster 
around a number of large nodes. E.g. for XMPP this would be gmail, 
jabber.org, jabber.ccc.de (applause to their efforts on making 
themselves unreliable!), ...
Interdomain federation is hard, especially delivering the same user 
experience as between users on the same domain.


I understand the rationale. I just don't agree with it.

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Andreas Kuckartz]

Carlo v. Loesch:
> but if you ask me I would say because if
> taken in on a global scale, social graph data gives you enough
> information to be a threat to liberty and democracy of entire
> populations. I presume you can find plenty of scientific analysis,
> ...

That is correct. Determining the social graph has for a very long time
been one of the tools of all repressive regimes.

> #youbroketheinternet is only ironically pointing a finger, since we
> know that governments are operating in best intentions like everyone
> else..

Having followed recent discussions around #youbroketheinternet I fear
that the second half of the sentence was not meant ironically. I
definitely disagree with that "best intentions" statement.

Different views regarding the motives of an attacker can lead to
differences regarding attack models and defenses.

> Having no federation at least doesn't introduce yet another
> huge possibility for security problems and as long as you own the source
> code and aren't forced to use anybody's specific offering it is highly
> inadeguate to call such a software a silo.

In case others are not yet aware: #youbroketheinternet is not only
explicitly opposed to federation but not even interested in
interoperability with federated communication networks. That is their
decision but I do not think that this helps users.

> By conseguence interoperability and "open standards" are no relevant goal:
> They were introduced in order to make companies have their proprietary 
> technology
> speak a common language - but since proprietary technology by design cannot be
> reliably respectful of privacy, we must design our future communication paths
> free of proprietary contributions.

I understand that #youbroketheinternet is not interested in
interoperability and open standards. That is one reason why I am
convinced that it will be far less relevant than some people hope it
will be.

Open standards can be "reliably respectful of privacy". They do not
necessarily contain any proprietary technologies. Maybe SMTP is bad due
to privacy issues especially regarding meta-data. But I think it would
be very wrong to underestimate the effect this standard has had in
enabling worldwide communication using the Internet. And as far as I
know the privacy issues were not built in deliberately.

BTW: Both the Tor and the GNUnet projects even support users of
Microsoft Windows while at the same time informing them that to "Stop
using Windows" is important.

> As long as there is a well-defined and reviewed GNU licensed codebase,

Which license exactly? One which is interoperable with ASF projects?

Cheers,
Andreas

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Thijs Alkemade]

On 18 nov. 2013, at 23:49, Carlo v. Loesch  wrote:

> On 11/18/2013 01:53 PM, Florian Zeitz wrote:
>> On 18.11.2013 13:38, Steffen Larsen wrote:
>>> Well you can €œalways” run XMPP on top of TOR if you like that, if it is 
>>> the S2S routing that bothers you. :-)
> 
> Not so simple.. S2S protocols expect you to have a well-defined domain name
> so it takes some tweaking to use a XXX.onion instead - especially if you'd
> like to have enhanced forward secrecy by embedding TLS: how the hell will
> you validate a .onion certificate? This would require a whole new XEP and
> a certification strategy to go with it.

Federating over hidden services requires some extra work, but it’s not that
hard. I’ve written a Prosody module for it, which can be found at [1]. Some
more background at [2].

Tor already offers forward secrecy, if I remember correctly it uses TLS with
EDH. Unless you want to assert a clearnet identity, I don't see the added
benefit of using TLS when accessing a hidden service.

For s2s, you have the same solution as with most servers currently: dialback.
.onion addresses being cryptographically verified makes this actually secure
in this case. This would work even when federating between hidden services and
normal XMPP servers (although the normal server needs Tor access, of course,
and the hidden service must keep in mind to always use Tor to dialback).

[1] = https://code.google.com/p/prosody-modules/wiki/mod_onions
[2] = 
https://blog.thijsalkema.de/blog/2013/06/11/xmpp-federation-over-tor-hidden-services/

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Carlo v. Loesch]

Since I've kind of been summoned, some observations to several mails in a 
single reply.


On 11/18/2013 10:30 AM, Andreas Kuckartz wrote:
> Peter Saint-Andre some time ago wrote:
>> > On 7/16/13 4:27 AM, Carlo v. Loesch wrote:
>>> >> Since XMPP isn't suitable for keeping meta-data private I would 
>>> >> presume that e2e privacy is out of scope for this mailing list, 
>>> >> really.
>> > 
>> > True.
> Where would the topic e2e privacy for XMPP be "in scope" ?

That's the point, XMPP not being really suited to today's needs of privacy.

> There exist people who mention XMPP as belonging to "faulty
> technologies" for which they want to create alternatives:
> http://youbroketheinternet.org/

#youbroketheinternet emerged out of the Social Swarm and GNU consensus
initiatives since this summer we realized that it is not enough to just
fix social networking. We need to fix the entire network stack.

We consider transaction data security one of the primary aims we strive
for for future communication technology. We didn't really detail why, but
if you ask me I would say because if taken in on a global scale, social
graph data gives you enough information to be a threat to liberty and
democracy of entire populations. I presume you can find plenty of
scientific analysis, if not regarding the Internet, then regarding the
operation techniques of the "German Democratic Republic." The Stasi
obviously being ridiculous compared to what we are experiencing today.

#youbroketheinternet is only ironically pointing a finger, since we know
that governments are operating in best intentions like everyone else..
unfortunately however some of them ignored all the constitutions, leading us
on a slippery slope towards totalitarian control (that's why constitutions
exist).

> And I try to find out what can be done to improve XMPP regarding
> security and privacy.

What happened to Encrypted Sessions? I think it was something similar to
OTR, but properly integrated to avoid typical failures like OTR trying
to send over a channel which no longer exists and whose DH key exchange
has long vanished. Still that is just end-to-end encryption and not very
sufficient in the face of the global not-always-passive adversary. No
surprise advanced users are using OTR on silo servers to avoid federation,
and combine it with Tor.


On 11/18/2013 01:53 PM, Florian Zeitz wrote:
> On 18.11.2013 13:38, Steffen Larsen wrote:
>> Well you can €œalways” run XMPP on top of TOR if you like that, if it is 
>> the S2S routing that bothers you. :-)

Not so simple.. S2S protocols expect you to have a well-defined domain name
so it takes some tweaking to use a XXX.onion instead - especially if you'd
like to have enhanced forward secrecy by embedding TLS: how the hell will
you validate a .onion certificate? This would require a whole new XEP and
a certification strategy to go with it.

> I think we might actually have gotten to the point where stanza routing
> is what bothers people.
> I.e. having a to and from stamped on a stanza. I don't think it's
> possible to get around the servers knowing this in XMPP. Between
> servers, we hope encryption helps to hide this information.

The reliability of TLS within servers is another large pain, but yes,
the froms and tos are the problem and I am very doubtful of strategies
that simply try to obfuscate those with temporary aliases. Onion
routing has an advantage: it has been peer reviewed by the best financed
cryptography institution on earth.


On 11/18/2013 02:04 PM, Hannes Tschofenig wrote:
> I briefly looked at a Mumble project, which uses IM over Tor, when it
> was mentioned on the IETF perpass list. Here were my thoughts:
> http://www.ietf.org/mail-archive/web/perpass/current/msg00215.html   

Let me cite from that mail.

> I might be incorrect in my assessment. I found some information but it was 
> mostly irrelevant to make a good assessment about the security and privacy 
> properties about it.

It's easy. Mumble uses a star topology with clients connecting to a server.
It uses TLS with a persistent certificate. Clients pin down that certificate
for all time and generate a client certificate for authentication with the
server when asked for. If the user loses its certificate, the username is gone.
Reserve a name and build up reputation. TOFU strategy on both sides. If an
attacker wants to listen in, it needs to MITM the very first exchange.

With Tor in the mix the model changes a lot, see below.

> There seems to be the (wrong) believe that if you publish software as open 
> source then everyone can look at the code and the quality will be good.

But it is also unfair to criticize software for not having been reviewed
yet, especially if it solves problems that other software doesn't solve.
In that case the criticism should read "This software could be interesting,
somebody should finance a good peer review ASAP." We can't always wait for
a whistleblower to show us material that tells us that the world's larges

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Ralph Meijer]

On 2013-11-18 13:07, Andreas Kuckartz wrote:
> Simon Tennant:
>> IMHO, e2e security would probably make more sense as a XEP and working
>> group that has the time to zoom into all the implementation details.
> 
> Can that be solved by an XEP ?
> 
> What about this IETF draft? (I still have to read it)
> 
> End-to-End Object Encryption and Signatures for the Extensible Messaging
> and Presence Protocol (XMPP)
> draft-miller-xmpp-e2e-06
> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e/
> 
> There exist people who mention XMPP as belonging to "faulty
> technologies" for which they want to create alternatives:
> http://youbroketheinternet.org/

>From a first glance, it looks like some PSYC proponents are involved
with this. Here is their stand on the brokenness of XMPP:

http://about.psyc.eu/Jabber

Also, hi fippo!

-- 
ralphm

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Hannes Tschofenig]

It really depends what threats you are concerned about, Steffen.

I briefly looked at a Mumble project, which uses IM over Tor, when it 
was mentioned on the IETF perpass list. Here were my thoughts:

http://www.ietf.org/mail-archive/web/perpass/current/msg00215.html  

Ciao
Hannes

Am 18.11.13 13:38, schrieb Steffen Larsen:

Hi,

On 18 Nov 2013, at 13:07, Andreas Kuckartz  wrote:


Simon Tennant:

IMHO, e2e security would probably make more sense as a XEP and working
group that has the time to zoom into all the implementation details.


Can that be solved by an XEP ?

What about this IETF draft? (I still have to read it)

End-to-End Object Encryption and Signatures for the Extensible Messaging
and Presence Protocol (XMPP)
draft-miller-xmpp-e2e-06
https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e/

There exist people who mention XMPP as belonging to "faulty
technologies" for which they want to create alternatives:
http://youbroketheinternet.org/

And I try to find out what can be done to improve XMPP regarding
security and privacy.



Well you can “always” run XMPP on top of TOR if you like that, if it is the S2S 
routing that bothers you. :-)



Cheers,
Andreas


On 18 November 2013 10:30, Andreas Kuckartz mailto:a.kucka...@ping.de>> wrote:

Peter Saint-Andre some time ago wrote:

On 7/16/13 4:27 AM, Carlo v. Loesch wrote:

Since XMPP isn't suitable for keeping meta-data private I would
presume that e2e privacy is out of scope for this mailing list,
really.


True.


Where would the topic e2e privacy for XMPP be "in scope" ?

Cheers,
Andreas



/Steffen

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Florian Zeitz]

On 18.11.2013 13:38, Steffen Larsen wrote:
> Hi,
> 
> On 18 Nov 2013, at 13:07, Andreas Kuckartz  wrote:
> 
>> Simon Tennant:
>>> IMHO, e2e security would probably make more sense as a XEP and working
>>> group that has the time to zoom into all the implementation details.
>>
>> Can that be solved by an XEP ?
>>
>> What about this IETF draft? (I still have to read it)
>>
>> End-to-End Object Encryption and Signatures for the Extensible Messaging
>> and Presence Protocol (XMPP)
>> draft-miller-xmpp-e2e-06
>> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e/
>>
>> There exist people who mention XMPP as belonging to "faulty
>> technologies" for which they want to create alternatives:
>> http://youbroketheinternet.org/
>>
>> And I try to find out what can be done to improve XMPP regarding
>> security and privacy.
>>
> 
> Well you can “always” run XMPP on top of TOR if you like that, if it is the 
> S2S routing that bothers you. :-)
> 

I think we might actually have gotten to the point where stanza routing
is what bothers people.
I.e. having a to and from stamped on a stanza. I don't think it's
possible to get around the servers knowing this in XMPP. Between
servers, we hope encryption helps to hide this information.

End-to-end encryption IMHO is a separate issue. It is currently in scope
for the XMPP WG[1] at the IETF. I also doubt anyone will complain if it
is discussed here, or on the XMPP-security[2] mailing list.
I think currently our best bet is Matthew Millers E2EE draft. Though I
have to say it's rather complex. It also depends on the JOSE work being
finished. There is some hope though that implementations would be rather
simple once JOSE implementations are readily available.
Peter Saint-Andre has also repeatedly stated he is working with the OTR
folks towards an RFC document describing OTR.

A related issue I'd like us thinking about is trust, key distribution
and switching devices in general. It would be good if we could come up
with a way that allows each device to have its own private/public key
pair, but not requiring users to trust each public key individually.
Problems when switching resources during an encrypted conversations are
also way to commonplace right now. I think if we want any acceptance
these are issues we should try to solve.

Regards,
Florob

[1] https://tools.ietf.org/wg/xmpp/
[2] http://mail.jabber.org/mailman/listinfo/security

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Steffen Larsen]

Hi,

On 18 Nov 2013, at 13:07, Andreas Kuckartz  wrote:

> Simon Tennant:
>> IMHO, e2e security would probably make more sense as a XEP and working
>> group that has the time to zoom into all the implementation details.
> 
> Can that be solved by an XEP ?
> 
> What about this IETF draft? (I still have to read it)
> 
> End-to-End Object Encryption and Signatures for the Extensible Messaging
> and Presence Protocol (XMPP)
> draft-miller-xmpp-e2e-06
> https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e/
> 
> There exist people who mention XMPP as belonging to "faulty
> technologies" for which they want to create alternatives:
> http://youbroketheinternet.org/
> 
> And I try to find out what can be done to improve XMPP regarding
> security and privacy.
> 

Well you can “always” run XMPP on top of TOR if you like that, if it is the S2S 
routing that bothers you. :-)


> Cheers,
> Andreas
> 
>> On 18 November 2013 10:30, Andreas Kuckartz > > wrote:
>> 
>>Peter Saint-Andre some time ago wrote:
>>> On 7/16/13 4:27 AM, Carlo v. Loesch wrote:
 Since XMPP isn't suitable for keeping meta-data private I would
 presume that e2e privacy is out of scope for this mailing list,
 really.
>>> 
>>> True.
>> 
>>Where would the topic e2e privacy for XMPP be "in scope" ?
>> 
>>Cheers,
>>Andreas


/Steffen

smime.p7s
Description: S/MIME cryptographic signature

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Andreas Kuckartz]

Simon Tennant:
> IMHO, e2e security would probably make more sense as a XEP and working
> group that has the time to zoom into all the implementation details.

Can that be solved by an XEP ?

What about this IETF draft? (I still have to read it)

End-to-End Object Encryption and Signatures for the Extensible Messaging
and Presence Protocol (XMPP)
draft-miller-xmpp-e2e-06
https://datatracker.ietf.org/doc/draft-miller-xmpp-e2e/

There exist people who mention XMPP as belonging to "faulty
technologies" for which they want to create alternatives:
http://youbroketheinternet.org/

And I try to find out what can be done to improve XMPP regarding
security and privacy.

Cheers,
Andreas

> On 18 November 2013 10:30, Andreas Kuckartz  > wrote:
> 
> Peter Saint-Andre some time ago wrote:
> > On 7/16/13 4:27 AM, Carlo v. Loesch wrote:
> >> Since XMPP isn't suitable for keeping meta-data private I would
> >> presume that e2e privacy is out of scope for this mailing list,
> >> really.
> >
> > True.
> 
> Where would the topic e2e privacy for XMPP be "in scope" ?
> 
> Cheers,
> Andreas

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Daniele Ricci]

I think we should go ahead by steps on this. I will shortly begin
implementing a CPIM-based XEP-0027 [1] to at least avoid replay
attacks and some other security issues. We could begin by defining a
XEP for that and then move on to e2e encryption which is much more
complex. Just my two cents anyway.

[1] http://xmpp.org/extensions/xep-0027.html‎

On Mon, Nov 18, 2013 at 11:21 AM, Simon Tennant  wrote:
> IMHO, e2e security would probably make more sense as a XEP and working group
> that has the time to zoom into all the implementation details.
>
> S.
>
>
> On 18 November 2013 10:30, Andreas Kuckartz  wrote:
>>
>> Peter Saint-Andre some time ago wrote:
>> > On 7/16/13 4:27 AM, Carlo v. Loesch wrote:
>> >> Since XMPP isn't suitable for keeping meta-data private I would
>> >> presume that e2e privacy is out of scope for this mailing list,
>> >> really.
>> >
>> > True.
>>
>> Where would the topic e2e privacy for XMPP be "in scope" ?
>>
>> Cheers,
>> Andreas
>
>
>
>
> --
> Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
> goo.gl/tQgxP



-- 
Daniele

Re: [Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Simon Tennant]

IMHO, e2e security would probably make more sense as a XEP and working
group that has the time to zoom into all the implementation details.

S.


On 18 November 2013 10:30, Andreas Kuckartz  wrote:

> Peter Saint-Andre some time ago wrote:
> > On 7/16/13 4:27 AM, Carlo v. Loesch wrote:
> >> Since XMPP isn't suitable for keeping meta-data private I would
> >> presume that e2e privacy is out of scope for this mailing list,
> >> really.
> >
> > True.
>
> Where would the topic e2e privacy for XMPP be "in scope" ?
>
> Cheers,
> Andreas
>



-- 
Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours:
goo.gl/tQgxP

[Standards] e2e privacy for XMPP Re: RFC 3923 (e2e with S/MIME) and OpenPGP

[Andreas Kuckartz]

Peter Saint-Andre some time ago wrote:
> On 7/16/13 4:27 AM, Carlo v. Loesch wrote:
>> Since XMPP isn't suitable for keeping meta-data private I would 
>> presume that e2e privacy is out of scope for this mailing list, 
>> really.
> 
> True.

Where would the topic e2e privacy for XMPP be "in scope" ?

Cheers,
Andreas