[Standards] New XMPP Use Case: Private Media Networks

[Dirk Meyer]

Hi,

I wrote a first draft of a possible XMPP extension which opens new use
cases for XMPP. But before I go into details, let me introduce
myself: my name is Dirk Meyer and I work at the TZI which is part of
the University of Bremen. My doctor thesis is about media networks and
possible new use cases if all devices of a user can interact with each
other.

Unlike a HTTP based approach like UPnP, XMPP provides a much better
core for what I call a "Personal Media Network". My first (not
finished) draft can be found at

http://www.tzi.de/~dmeyer/media-network.html

Before finishing it and sending it to the XMPP council I want to ask on
this list for some opinions about it. It clearly uses XMPP in a way
XMPP was not indented to be used, but it could be the base for new use
cases (examples of such use cases are in the document).

Besides working at the TZI I'm also maintainer of the Freevo project
and want to use the XMPP based private network as communication
between different media applications inside Freevo. I already have a
small Python based XMPP implementation specially designed for this use
cases (not in public svn yet).

So, if you have some free minutes, please take a look at my draft and
tell me what you think about this idea.

Regards,

Dirk

--
The world is full of willing people -- some willing to work and some
willing to let them. - Robert Frost.

[Jehan]

I have just skimmed through the XEP. I won't give any technical consideration right now because I have not read this with enough attention (it's late where I am! And probably I am not the most specialist of such things). Anyway if my opinion has any value: this is a nice idea!

For me the only point really important will be anyway the security, because XMPP can probably be very secure, and I will already trust far more the Jabber network than any of the other IM networks which are for most of them not at all secure (and even more than Skype which is the one said very secure). But the current implementation and uses of XMPP are still not sufficient for me for such sensible uses. Anyway you are apparently studying the security consideration very fairly in your XEP already.
I would add also one security layer yet: some commands should be makable only locally (for instance on the machine itself). For instance, imagine you can control the heater, the aeration system or anything like this. You should set some limits locally that even the "owner" of the devices cannot change through one's account (but one can do it locally if one has physical access to the device for instance, or other access very secure). Or maybe this owner's account could run any command, but for critical one, they would be a second layer of security (like another password to give every time you make such a command, etc.).

I am considering the fact that often the main security breach is the human being. So what if someone can use your account: if you set a poorly secure password like most people; or if your Jabber client connects automatically on your main computer and gave access to this to someone; or simply when you leave your desktop 5 minutes without unconnecting from Jabber (forgetting this account is so sensible), etc. Many security attacks rely on the human flaws (unless you are paranoid).

But given all this to be considered deeply, this can be funny, though not very good for our poor earth with all machines in our houses always on... :-/

And now all we are missing is our machines being able to "speak" XMPP and connect to the network.
So now, if you'll excuse me, I have to "tell" my coffee machine to prepare some (coffee) for me, I see it is on my roster (pfff, again chatting with the washing machine I guess! They are all the same lazy machines, and after they don't do good work!). :p

Jehan

[Dave Cridland]

On Tue May 20 20:28:34 2008, Dirk Meyer wrote:
> I wrote a first draft of a possible XMPP extension which opens new
> use
> cases for XMPP. But before I go into details, let me introduce
> myself: my name is Dirk Meyer and I work at the TZI which is part of
> the University of Bremen. My doctor thesis is about media networks
> and
> possible new use cases if all devices of a user can interact with
> each
> other.
>
>
This looks interesting. Particularly so because of the case allowing
information flow between "public" services and "private" media
services.

I'm thinking particularly of data stores such as the BBC's Programmes
thing, but this would be equally applicable to a number of cases I'd
imagine, including being able to watch something my neighbour had
recorded if I had their permission.

This notion of bring these traditionally isolated networks into
(secure) contact with the internet as a whole seems like a good
enough reason to go this route on its own - I really like the
symmetry between accessing your local media store and someone else's
one remotely via essentially the same mechanism.


> Unlike a HTTP based approach like UPnP, XMPP provides a much better
> core for what I call a "Personal Media Network".

I think that's basically a good plan, but one of the key features of
UPnP is that it's Plug 'n' Play - specifically, dropping a device
onto a network essentially makes the device attach and become
available to the network. Your proposal misses this out, and I think
that's a critical shortcoming.

This can be addressed easily by bootstrapping via Link Local XMPP
(XEP-0174), and using some simple authentication mechanism - akin to
a Bluetooth pairing - to allow a push of configuration data to "make
the jump" to client/server XMPP, although that might be somewhat
overkill - but it allows for physically isolated networks to operate
perfectly well, too.

> My first (not
> finished) draft can be found at
>
> http://www.tzi.de/~dmeyer/media-network.html
>
> Before finishing it and sending it to the XMPP council I want to
> ask on
> this list for some opinions about it. It clearly uses XMPP in a way
> XMPP was not indented to be used, but it could be the base for new
> use
> cases (examples of such use cases are in the document).
>
>
I don't entirely agree it's using XMPP in an unintended way, really -
the use of C2C pubsub is unusual, though I like the concept.

One thing that does immediately ring alarm bells for me, personally,
is that the design conflates several orthogonal aspects of
inter-device communication. There's a number of reasons I don't like
this, in particular because if other protocols and/or profiles want
to use these, they'd have to reference your XEP piecewise, which
makes these new XEPs harder to follow.

I'd encourage you to split out each concept into a distinct document:

a) One that describes C2C PubSub - maybe, although it's potentially a
small enough adaptation that it'll need nothing new.

b) One that describes C2C security, although admittedly you may wish
to punt on this, and simply note that it's an issue that needs
solving.

c) One that describes a media device framework using XMPP. I'd fold
in the "pairing" bootstrap from Link-Local here, but again, this
might need its own document if it turns out to be "too big".

I think that individually, these would be more readable.

However, I'd reiterate that the subject matter and general concept
seems solid to me, and well worth persuing.

Dave.
--
Dave Cridland - mailto:dave (AT) cridland (DOT) net - xmpp:dwd (AT) jabber (DOT) org
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

[Dirk Meyer]

JabberForum wrote:
> For me the only point really important will be anyway the security,
> because XMPP can probably be very secure, and I will already trust far
> more the Jabber network than any of the other IM networks which are for
> most of them not at all secure (and even more than Skype which is the
> one said very secure). But the current implementation and uses of XMPP
> are still not sufficient for me for such sensible uses. Anyway you are
> apparently studying the security consideration very fairly in your XEP
> already.

Thanks. Yes, security is the main problem here. I trust the Jabber
server, but when it comes to personal data, I only trust applications
I control. And based on my XEP it would be possible to do some nasty
stuff.

> I would add also one security layer yet: some commands should be
> makable only locally (for instance on the machine itself). For instance,
> imagine you can control the heater, the aeration system or anything like
> this. You should set some limits locally that even the "owner" of the
> devices cannot change through one's account (but one can do it locally
> if one has physical access to the device for instance, or other access
> very secure). Or maybe this owner's account could run any command, but
> for critical one, they would be a second layer of security (like another
> password to give every time you make such a command, etc.).

It should be possible to only allow services for the owner. That will
be defined in the yet-to-be-written Access Control List section of the
document. Your local idea sounds nice and by accident it is already
defined. If a device only uses link-local communication and does not
register at the XMPP server, only local communication will be
possible. But I will keep the local stuff in consideration when
defining the access control list.

> I am considering the fact that often the main security breach is the
> human being. So what if someone can use your account: if you set a
> poorly secure password like most people; or if your Jabber client
> connects automatically on your main computer and gave access to this to
> someone; or simply when you leave your desktop 5 minutes without
> unconnecting from Jabber (forgetting this account is so sensible), etc.
> Many security attacks rely on the human flaws (unless you are
> paranoid).

You can not prevent a stupid user. But the XMPP server account
password is totally useless since the network does not trust the
server. But if I have a main control app on my laptop running and you
get access to my laptop ... well, you have access.


Thanks for the feedback.


Dirk

--
This fortune would be seven words long if it were six words shorter.

[Dirk Meyer]

Hi,

Dave Cridland wrote:
> This looks interesting. Particularly so because of the case allowing
> information flow between "public" services and "private" media
> services.
>
> I'm thinking particularly of data stores such as the BBC's Programmes
> thing, but this would be equally applicable to a number of cases I'd
> imagine, including being able to watch something my neighbour had
> recorded if I had their permission.

Or even better: if you want to record two shows but only have one
DVB-T receiver and your neighbour does not need his at that time, you
could use it (with his permission).

> This notion of bring these traditionally isolated networks into
> (secure) contact with the internet as a whole seems like a good
> enough reason to go this route on its own - I really like the
> symmetry between accessing your local media store and someone else's
> one remotely via essentially the same mechanism.

Thanks.

>> Unlike a HTTP based approach like UPnP, XMPP provides a much better
>> core for what I call a "Personal Media Network".
>
> I think that's basically a good plan, but one of the key features of
> UPnP is that it's Plug 'n' Play - specifically, dropping a device
> onto a network essentially makes the device attach and become
> available to the network. Your proposal misses this out, and I think
> that's a critical shortcoming.

You can not have plug and play AND security. In fact, there is a UPnP
security document but I know no device implementing it. So it has to
be plug, insert a pin, play.

> This can be addressed easily by bootstrapping via Link Local XMPP
> (XEP-0174), and using some simple authentication mechanism - akin to
> a Bluetooth pairing - to allow a push of configuration data to "make
> the jump" to client/server XMPP, although that might be somewhat
> overkill - but it allows for physically isolated networks to operate
> perfectly well, too.

Section 8.2 describes how to find an authorization node link local and
the peering in 8.3 is similar (from the users point of view) to
bluetooth peering. For link-local devices it is more or less plug and
play (which the additional pin).

> I don't entirely agree it's using XMPP in an unintended way, really -
> the use of C2C pubsub is unusual, though I like the concept.

Again, thanks.

> One thing that does immediately ring alarm bells for me, personally,
> is that the design conflates several orthogonal aspects of
> inter-device communication. There's a number of reasons I don't
> like this, in particular because if other protocols and/or profiles
> want to use these, they'd have to reference your XEP piecewise,
> which makes these new XEPs harder to follow.
>
> I'd encourage you to split out each concept into a distinct document:
>
> a) One that describes C2C PubSub - maybe, although it's potentially a
> small enough adaptation that it'll need nothing new.

LOL, if you could see my private svn you would see that I moved the
whole section 4 (Service Provider and Controller) in an extra
document, moved it back and the same again. They kept referencing each
other. :) But only moving the C2C PubSub away sounds like a good
idea.

> b) One that describes C2C security, although admittedly you may wish
> to punt on this, and simply note that it's an issue that needs
> solving.

I don't understand what you mean.

> c) One that describes a media device framework using XMPP. I'd fold
> in the "pairing" bootstrap from Link-Local here, but again, this
> might need its own document if it turns out to be "too big".

and d) I guess there could be the need for one higher level bytestream
XEP. This XEP could use direct connections, a TURN or SOCKS5 server
and IBB as fallback. Having a bi-directional datastream XEP could be
very usefull and for transmitting video files, IBB is not an
option. Direct connections may be possible if one node is not behind a
NAT/firewall (e.g. a mobile phone) and also with IPv6. While my home
network is behind an IPv4 NAT, I have a /64 IPv6 network with public
IP addresses for all my devices at home.

> However, I'd reiterate that the subject matter and general concept
> seems solid to me, and well worth persuing.

I like to hear that. :)

Thanks for the feedback,


Dirk

--
Microsoft Windows didn't get as bad as it is overnight -- it took over ten
years of careful development

[Dirk Meyer]

Dave Cridland wrote:
> One thing that does immediately ring alarm bells for me, personally,
> is that the design conflates several orthogonal aspects of
> inter-device communication. There's a number of reasons I don't
> like this, in particular because if other protocols and/or profiles
> want to use these, they'd have to reference your XEP piecewise,
> which makes these new XEPs harder to follow.

After some thinking, I guess I will split my proposal into three XEPs:

1. Service Provider including section 4. I will also add
variable monitoring to it.

2. Client-to-Client Communication including section 6. After reading
some more XEPs, I guess jingle is the way to go to open the stream
between clients. I will change that.

3. Authorization Service will include sections 7 and 8.

Sections 3 and 5 will be moved to one of these three, I'm not sure
now.

I would like to start with the first one, sending it to the XMPP
council next week. One question: the doc says I should send it to
http://www.xmpp.org/extensions/inbox/. But looking at that dir, I see
only html files. Doesn't it make more sense to upload the xml file?
What is the correct way to do this?


Dirk

--
Earn cash in your spare time - blackmail friends.

[Peter Saint-Andre]

On 05/30/2008 12:12 PM, Dirk Meyer wrote:
> Dave Cridland wrote:
>> One thing that does immediately ring alarm bells for me, personally,
>> is that the design conflates several orthogonal aspects of
>> inter-device communication. There's a number of reasons I don't
>> like this, in particular because if other protocols and/or profiles
>> want to use these, they'd have to reference your XEP piecewise,
>> which makes these new XEPs harder to follow.
>
> After some thinking, I guess I will split my proposal into three XEPs:
>
> 1. Service Provider including section 4. I will also add
> variable monitoring to it.
>
> 2. Client-to-Client Communication including section 6. After reading
> some more XEPs, I guess jingle is the way to go to open the stream
> between clients. I will change that.
>
> 3. Authorization Service will include sections 7 and 8.
>
> Sections 3 and 5 will be moved to one of these three, I'm not sure
> now.
>
> I would like to start with the first one, sending it to the XMPP
> council next week. One question: the doc says I should send it to
> http://www.xmpp.org/extensions/inbox/. But looking at that dir, I see
> only html files. Doesn't it make more sense to upload the xml file?
> What is the correct way to do this?

Please send the XML file to <mailto:editor (AT) xmpp (DOT) org>, or directly to me
off-list. :)

I'll try to comment on your proposal here soon.

Peter

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

[Peter Saint-Andre]

On 05/20/2008 1:28 PM, Dirk Meyer wrote:
> Hi,
>
> I wrote a first draft of a possible XMPP extension which opens new use
> cases for XMPP. But before I go into details, let me introduce
> myself: my name is Dirk Meyer and I work at the TZI which is part of
> the University of Bremen. My doctor thesis is about media networks and
> possible new use cases if all devices of a user can interact with each
> other.
>
> Unlike a HTTP based approach like UPnP, XMPP provides a much better
> core for what I call a "Personal Media Network". My first (not
> finished) draft can be found at
>
> http://www.tzi.de/~dmeyer/media-network.html

First, thanks for writing this.

A few comments...

You might want to make it clear that by "server" you don't mean "XMPP
server" and by "client" you don't mean "XMPP client".

In your architecture, is a "node" (1) <localpart (AT) domain (DOT) tld> or (2)
<localpart (AT) domain (DOT) tld/resource>? If (2), does each application have its
own certificate?

About authorization, you might want to check out XEP-0235.

About security, what about using something like XTLS?

http://www.xmpp.org/extensions/inbox/xtls.html

That needs a lot of work, but it seems similar to what you are proposing.

> Before finishing it and sending it to the XMPP council I want to ask on
> this list for some opinions about it. It clearly uses XMPP in a way
> XMPP was not indented to be used, but it could be the base for new use
> cases (examples of such use cases are in the document).

Well, HTTP is being used for things that Tim Berners-Lee never intended,
so who are we to complain about creative uses of XMPP? :)

Peter

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

[Dirk Meyer]

Hi,

Peter Saint-Andre wrote:
> You might want to make it clear that by "server" you don't mean "XMPP
> server" and by "client" you don't mean "XMPP client".

I guess I should use my own words "service provider" and "controller"
all the time to avoid confusion.

> In your architecture, is a "node" (1) <localpart (AT) domain (DOT) tld> or (2)
> <localpart (AT) domain (DOT) tld/resource>? If (2), does each application have its
> own certificate?

(2) and each application has its own certificate.

> About authorization, you might want to check out XEP-0235.

I already was thinking about this. I have to do some more
thinking. Since I'm about to split the doc into three XEP proposals,
the authorization doc will be send to you later.

> About security, what about using something like XTLS?
> http://www.xmpp.org/extensions/inbox/xtls.html

I was thinking about DTLS, I did not know that there already is
something in the inbox. But not many tls implementations support it,
my python bindings use tlslite which lacks dlls support. I know it is
not a good reason, but since all XMPP clients already support
<starttls> for streams this looks like a simpler idea. And the
overhead IBB + <starttls> is similar to XTLS, with stream compression
in the inside even less. And when not using IBB, it can reduce the
server traffic. I will do some more thinking about this.

>> Before finishing it and sending it to the XMPP council I want to ask on
>> this list for some opinions about it. It clearly uses XMPP in a way
>> XMPP was not indented to be used, but it could be the base for new use
>> cases (examples of such use cases are in the document).
>
> Well, HTTP is being used for things that Tim Berners-Lee never intended,
> so who are we to complain about creative uses of XMPP? :)

:)


Dirk

--
Dancing is a vertical expression of a horizontal desire.

[Peter Saint-Andre]

On 06/04/2008 2:13 AM, Dirk Meyer wrote:
>
> Peter Saint-Andre wrote:
>
>> About security, what about using something like XTLS?
>> http://www.xmpp.org/extensions/inbox/xtls.html
>
> I was thinking about DTLS, I did not know that there already is
> something in the inbox. But not many tls implementations support it,
> my python bindings use tlslite which lacks dlls support. I know it is
> not a good reason, but since all XMPP clients already support
> <starttls> for streams this looks like a simpler idea. And the
> overhead IBB + <starttls> is similar to XTLS, with stream compression
> in the inside even less. And when not using IBB, it can reduce the
> server traffic. I will do some more thinking about this.

Well XTLS is not well-defined yet, but I will turn my attention to it
soon. The approach of starttls and then IBB was mentioned by Justin
Karneges here:

http://mail.jabber.org/pipermail/security/2007-March/000018.html

And that seems reasonable to me.

Peter

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

[Dirk Meyer]

Peter Saint-Andre wrote:
> Well XTLS is not well-defined yet, but I will turn my attention to it
> soon. The approach of starttls and then IBB was mentioned by Justin
> Karneges here:
>
> http://mail.jabber.org/pipermail/security/2007-March/000018.html
>
> And that seems reasonable to me.

My fault. I only took a quick look at xtls and assumed it uses DTLS
(which is scary like Justin wrote). Now that I see that xtls always
uses <iq> and is in fact "normal" tls wrapped in XML it looks good to
me. If you turn your attention to it, I would like to help both
writing and implementing it. I have a small python XMPP implementation
here where I can add stuff like this very easy. The IBB + new stream
stuff is already implemented and works well.

When thinking about IBB + new stream + starttls vs. xtls I see the
following arguments:

xtls advantages:

1. xtls is faster to set up. It does not require to open an IBB,
SOCKS5 or maybe even Jingle to figure out what to use.

extra stream advantages:

1. Bypass the server by using SOCKS5

2. Reuse code used for link-local messaging

3. By using stream compression in the stream inside the IBB you can
save bandwidth

xtls has only one advantage but it is a huge one. One question remains
for both ways: how do I verify a certificate? And does every entity
has a certificate or only every user? Maybe the user signs all its
entities? Using an existing CA you have to pay a lot of money; users
don't like that :) And setting up your own CA is not that simple,
creating self-signed certificates on the other hand is an openssl
one-liner.


Dirk

--
When someone says, 'do you want my opinion?' - have you noticed that
it's always a negative one.

[Justin Karneges]

On Wednesday 04 June 2008 9:43 am, Dirk Meyer wrote:
> Peter Saint-Andre wrote:
> > Well XTLS is not well-defined yet, but I will turn my attention to it
> > soon. The approach of starttls and then IBB was mentioned by Justin
> > Karneges here:
> >
> > http://mail.jabber.org/pipermail/security/2007-March/000018.html
> >
> > And that seems reasonable to me.
>
> My fault. I only took a quick look at xtls and assumed it uses DTLS
> (which is scary like Justin wrote). Now that I see that xtls always
> uses <iq> and is in fact "normal" tls wrapped in XML it looks good to
> me.

XTLS as currently documented is not usable, in my opinion, because it doesn't
treat TLS like a stream. It expects each <iq> exchange to contain specific
TLS frames, which are not things applications normally know about. You'd
have to write a TLS parser to inspect data from your TLS library, chop them
up at TLS frame boundaries, and then wrap them correctly into <iq>. You may
even have some trouble determining the content of the frames you're sending.

DTLS would not have this problem as much, since it is designed as packetized,
but most people don't have access to DTLS implementations.

For XTLS to be usable, it would need to be adjusted to treat TLS like a
stream, where the <iq>-wrapped packets may contain arbitrary data (partial
TLS frames, multiple TLS frames, etc). If this is done, then we'd
additionally have to define a protocol that goes over the TLS stream (such as
an XML stream), since you could no longer use TLS frame boundaries to
determine message boundaries.

So at best, your comparison would have to be against an "adjusted" XTLS as I
described above.

> When thinking about IBB + new stream + starttls vs. xtls I see the
> following arguments:
>
> xtls advantages:
>
> 1. xtls is faster to set up. It does not require to open an IBB,
> SOCKS5 or maybe even Jingle to figure out what to use.

Indeed. However, the IBB approach should only amount to one extra round trip
(one iq exchange to establish the desire for an encrypted session and one iq
exchange for IBB, vs just one iq exchange for XTLS), which may not be so bad.

If we consider IBB to be a worthwhile approach, we could easily offer an
optional optimization whereby the encrypted session and IBB stream are
negotiated in a single iq round trip.

> extra stream advantages:
[...]
> 2. Reuse code used for link-local messaging

I think this is a really cool idea.

-Justin

[Peter Saint-Andre]

On 06/04/2008 12:35 PM, Justin Karneges wrote:
> On Wednesday 04 June 2008 9:43 am, Dirk Meyer wrote:
>> Peter Saint-Andre wrote:
>>> Well XTLS is not well-defined yet, but I will turn my attention to it
>>> soon. The approach of starttls and then IBB was mentioned by Justin
>>> Karneges here:
>>>
>>> http://mail.jabber.org/pipermail/security/2007-March/000018.html
>>>
>>> And that seems reasonable to me.
>> My fault. I only took a quick look at xtls and assumed it uses DTLS
>> (which is scary like Justin wrote). Now that I see that xtls always
>> uses <iq> and is in fact "normal" tls wrapped in XML it looks good to
>> me.
>
> XTLS as currently documented is not usable,

Right, that was a very early pass and never updated again. However I
think it would be good to update it using the approach you've outlined,
I just haven't found the time to do that.

/psa

[Peter Saint-Andre]

On 06/04/2008 10:43 AM, Dirk Meyer wrote:
> Peter Saint-Andre wrote:
>> Well XTLS is not well-defined yet, but I will turn my attention to it
>> soon. The approach of starttls and then IBB was mentioned by Justin
>> Karneges here:
>>
>> http://mail.jabber.org/pipermail/security/2007-March/000018.html
>>
>> And that seems reasonable to me.
>
> My fault. I only took a quick look at xtls and assumed it uses DTLS
> (which is scary like Justin wrote). Now that I see that xtls always
> uses <iq> and is in fact "normal" tls wrapped in XML it looks good to
> me. If you turn your attention to it, I would like to help both
> writing and implementing it. I have a small python XMPP implementation
> here where I can add stuff like this very easy. The IBB + new stream
> stuff is already implemented and works well.

That approach is not clear to me yet, but perhaps I haven't read your
document closely enough.

> When thinking about IBB + new stream + starttls vs. xtls I see the
> following arguments:
>
> xtls advantages:
>
> 1. xtls is faster to set up. It does not require to open an IBB,
> SOCKS5 or maybe even Jingle to figure out what to use.
>
> extra stream advantages:
>
> 1. Bypass the server by using SOCKS5

What attack does that solve? Your XEP-0065 negotiation packets still go
through the server.

> 2. Reuse code used for link-local messaging
>
> 3. By using stream compression in the stream inside the IBB you can
> save bandwidth
>
> xtls has only one advantage but it is a huge one. One question remains
> for both ways: how do I verify a certificate? And does every entity
> has a certificate or only every user? Maybe the user signs all its
> entities?

XMPP users don't have certificates right now, but they would need them
for all this end-to-end encryption stuff (however they could be
self-generated RSA/DSA keys, not CA-issued).

> Using an existing CA you have to pay a lot of money; users
> don't like that :) And setting up your own CA is not that simple,

https://www.xmpp.net/ :)

But we don't use that for end-user certs yet.

> creating self-signed certificates on the other hand is an openssl
> one-liner.

Right. We've also looked into short authentication strings (SAS) for use
in XTLS. But that would be farther out.

Peter

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

[Dirk Meyer]

Justin Karneges wrote:
> XTLS as currently documented is not usable, in my opinion, because it doesn't
> treat TLS like a stream. It expects each <iq> exchange to contain specific
> TLS frames, which are not things applications normally know about. You'd
> have to write a TLS parser to inspect data from your TLS library, chop them
> up at TLS frame boundaries, and then wrap them correctly into <iq>. You may
> even have some trouble determining the content of the frames you're sending.

Too bad I read this now that I just updated the xtls document. :(

So you suggest to handle xtls just like an in-band bytestream with a
tls layer on top of it? So unlike the current document you propose
that every time your tls lib sends something to a socket you put that
into a xmtls iq and send it away? Also for the handshake? I like the
way the handshake is now with all messages in one iq stanza.

But you are right, for application data it would be easier to send
what we get from the tls lib used. So one <message> could result in
more than one xtls <iq>.

Maybe keep the handshake as it is and just re-define application layer
data? Or everything as stream? I looked at the tls implementation I
use and keeping the handshake as it is seems to be very easy.

> DTLS would not have this problem as much, since it is designed as packetized,
> but most people don't have access to DTLS implementations.

I think that is a big no-go.

>> xtls advantages:
>>
>> 1. xtls is faster to set up. It does not require to open an IBB,
>> SOCKS5 or maybe even Jingle to figure out what to use.
>
> Indeed. However, the IBB approach should only amount to one extra round trip
> (one iq exchange to establish the desire for an encrypted session and one iq
> exchange for IBB, vs just one iq exchange for XTLS), which may not be so bad.

Well, we could handle xtls just like a special form of an IBB without
the extra IBB layer, just starting <xtls> and handle it as a
bytestream.

> If we consider IBB to be a worthwhile approach, we could easily offer an
> optional optimization whereby the encrypted session and IBB stream are
> negotiated in a single iq round trip.

It would be cool to negotiate extra stream parameter for IBB. Besides
TLS stream compresion comes to my mind.

| <iq type='set'
| from='romeo (AT) montague (DOT) net/orchard'
| to='juliet (AT) capulet (DOT) com/balcony'
| id='inband_1'>
| <open sid='mySID'
| block-size='4096'
| xmlns='http://jabber.org/protocol/ibb'>
| <feature>urn:xmpp:tmp:tls</feature>
| <feature>urn:xmpp:tmp:gzip</feature>
| </open>
| </iq>
|
| <iq type='result'
| from='juliet (AT) capulet (DOT) com/balcony'
| to='romeo (AT) montague (DOT) net/orchard'
| id='inband_1'>
| <feature>urn:xmpp:tmp:tls</feature>
| </iq>

In this example Romeo wants tls and gzip compression and Julia answers
with tls (because she can't do compression). Now the implementation
knows to start the tls handshake. XTLS should define (like it does
now) to remove the routing information since we don't need it.

Or (to make it simpler and not support compression) XTLS could define
that the IBB sid urn:xmpp:tmp:tls means to open an IBB with TLS for
client to client stanza exchange.

Many ideas, what do you prefer?

>> extra stream advantages:
> [...]
>> 2. Reuse code used for link-local messaging
>
> I think this is a really cool idea.

For entities in the same LAN link-local messaging is the easiest way
for client to client communication. See Sections 6.1 and 6.3 in
http://www.tzi.de/~dmeyer/media-network.html


Dirk

--
Hard work never killed anyone, but why give it a chance?

[Dirk Meyer]

Peter Saint-Andre wrote:
>> Using an existing CA you have to pay a lot of money; users
>> don't like that :) And setting up your own CA is not that simple,
>
> https://www.xmpp.net/ :)

If I'm paranoid why should I trust the same CA that verified the
server I use? Maybe they are both controlled by the same person.

>> creating self-signed certificates on the other hand is an openssl
>> one-liner.
>
> Right. We've also looked into short authentication strings (SAS) for use
> in XTLS. But that would be farther out.

IMHO we have several use cases here:

1. User to user communication: they can talk. Maybe they exchange a
shared secret somehow and can use that to verify the
fingerprint. No CA needed.

2. My service based idea. In that case bots "talk" to each other

a. Both peers belong to the same user. One other entity added them
to the network.

b. They belong to different user. The users trust each other

c. The service belongs to a company. E.g. you access flickr with
XMPP in the future. The Flickr service entity has a valid
certificate but the user has not.

Well, I think HOW to verify a certificate belongs to an extra
document.


Dirk

--
Stress is when You wake up screaming and then realize You haven't slept at all

[Peter Saint-Andre]

On 06/05/2008 3:55 AM, Dirk Meyer wrote:
> Peter Saint-Andre wrote:
>>> Using an existing CA you have to pay a lot of money; users
>>> don't like that :) And setting up your own CA is not that simple,
>> https://www.xmpp.net/ :)
>
> If I'm paranoid why should I trust the same CA that verified the
> server I use? Maybe they are both controlled by the same person.

You could do some research into the policies of the CA, determine its
ownership, follow up with the auditors, try to hack on its services in a
white-hat kind of way, etc. Due diligence. Or you could refuse to
connect to the Internet. I'm just pointing out that you don't
necessarily need to pay a lot of money to obtain a certificate, because
for the XMPP network we give away certificates for free (so far only
server certificates, but we could issue end-user certificates if we
wanted to).

>>> creating self-signed certificates on the other hand is an openssl
>>> one-liner.
>> Right. We've also looked into short authentication strings (SAS) for use
>> in XTLS. But that would be farther out.
>
> IMHO we have several use cases here:
>
> 1. User to user communication: they can talk. Maybe they exchange a
> shared secret somehow and can use that to verify the
> fingerprint. No CA needed.

Agreed.

> 2. My service based idea. In that case bots "talk" to each other
>
> a. Both peers belong to the same user. One other entity added them
> to the network.
>
> b. They belong to different user. The users trust each other

Why do they trust each other, and on what basis?

> c. The service belongs to a company. E.g. you access flickr with
> XMPP in the future. The Flickr service entity has a valid
> certificate but the user has not.
>
> Well, I think HOW to verify a certificate belongs to an extra
> document.

You bet.

Peter

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

[Peter Saint-Andre]

On 06/05/2008 3:44 AM, Dirk Meyer wrote:
> Justin Karneges wrote:
>> XTLS as currently documented is not usable, in my opinion, because it doesn't
>> treat TLS like a stream. It expects each <iq> exchange to contain specific
>> TLS frames, which are not things applications normally know about. You'd
>> have to write a TLS parser to inspect data from your TLS library, chop them
>> up at TLS frame boundaries, and then wrap them correctly into <iq>. You may
>> even have some trouble determining the content of the frames you're sending.
>
> Too bad I read this now that I just updated the xtls document. :(
>
> So you suggest to handle xtls just like an in-band bytestream with a
> tls layer on top of it? So unlike the current document you propose
> that every time your tls lib sends something to a socket you put that
> into a xmtls iq and send it away? Also for the handshake? I like the
> way the handshake is now with all messages in one iq stanza.

I think we'd allow you to batch the TLS messages together into one IQ if
desired -- a kind of pipelining, I suppose.

> But you are right, for application data it would be easier to send
> what we get from the tls lib used. So one <message> could result in
> more than one xtls <iq>.

Right.

> Maybe keep the handshake as it is and just re-define application layer
> data? Or everything as stream? I looked at the tls implementation I
> use and keeping the handshake as it is seems to be very easy.
>
>> DTLS would not have this problem as much, since it is designed as packetized,
>> but most people don't have access to DTLS implementations.
>
> I think that is a big no-go.
>
>>> xtls advantages:
>>>
>>> 1. xtls is faster to set up. It does not require to open an IBB,
>>> SOCKS5 or maybe even Jingle to figure out what to use.
>> Indeed. However, the IBB approach should only amount to one extra round trip
>> (one iq exchange to establish the desire for an encrypted session and one iq
>> exchange for IBB, vs just one iq exchange for XTLS), which may not be so bad.
>
> Well, we could handle xtls just like a special form of an IBB without
> the extra IBB layer, just starting <xtls> and handle it as a
> bytestream.

I think Justin's idea was that we have IBB, so why not use it? Just
trigger the special XTLS usage of IBB with an initial IQ in a different
namespace.

>> If we consider IBB to be a worthwhile approach, we could easily offer an
>> optional optimization whereby the encrypted session and IBB stream are
>> negotiated in a single iq round trip.
>
> It would be cool to negotiate extra stream parameter for IBB. Besides
> TLS stream compresion comes to my mind.
>
> | <iq type='set'
> | from='romeo (AT) montague (DOT) net/orchard'
> | to='juliet (AT) capulet (DOT) com/balcony'
> | id='inband_1'>
> | <open sid='mySID'
> | block-size='4096'
> | xmlns='http://jabber.org/protocol/ibb'>
> | <feature>urn:xmpp:tmp:tls</feature>
> | <feature>urn:xmpp:tmp:gzip</feature>
> | </open>
> | </iq>
> |
> | <iq type='result'
> | from='juliet (AT) capulet (DOT) com/balcony'
> | to='romeo (AT) montague (DOT) net/orchard'
> | id='inband_1'>
> | <feature>urn:xmpp:tmp:tls</feature>
> | </iq>
>
> In this example Romeo wants tls and gzip compression and Julia answers
> with tls (because she can't do compression). Now the implementation
> knows to start the tls handshake. XTLS should define (like it does
> now) to remove the routing information since we don't need it.

Won't the compression be automatically set up during TLS negotiation if
both sides support it?

> Or (to make it simpler and not support compression) XTLS could define
> that the IBB sid urn:xmpp:tmp:tls means to open an IBB with TLS for
> client to client stanza exchange.
>
> Many ideas, what do you prefer?

I don't like the idea of hardcoding the SID, that feels like a hack.

>>> extra stream advantages:
>> [...]
>>> 2. Reuse code used for link-local messaging
>> I think this is a really cool idea.
>
> For entities in the same LAN link-local messaging is the easiest way
> for client to client communication. See Sections 6.1 and 6.3 in
> http://www.tzi.de/~dmeyer/media-network.html

Agreed. We've never defined the link-local encryption very well, but
IMHO it would use standard XMPP stream semantics.

Peter

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

[Justin Karneges]

On Thursday 05 June 2008 2:44 am, Dirk Meyer wrote:
> Justin Karneges wrote:
> > XTLS as currently documented is not usable, in my opinion, because it
> > doesn't treat TLS like a stream. It expects each <iq> exchange to
> > contain specific TLS frames, which are not things applications normally
> > know about. You'd have to write a TLS parser to inspect data from your
> > TLS library, chop them up at TLS frame boundaries, and then wrap them
> > correctly into <iq>. You may even have some trouble determining the
> > content of the frames you're sending.
>
> Too bad I read this now that I just updated the xtls document. :(
>
> So you suggest to handle xtls just like an in-band bytestream with a
> tls layer on top of it? So unlike the current document you propose
> that every time your tls lib sends something to a socket you put that
> into a xmtls iq and send it away? Also for the handshake? I like the
> way the handshake is now with all messages in one iq stanza.

The handshake could still have all messages in one iq stanza. It's just that
we wouldn't enforce this behavior.

If a client sends one <iq> stanza containing a 2000 byte payload, great. If a
client sends 2000 <iq> stanzas each containing a one byte payload, .... not
so great, but it should be perfectly legal protocol.

It's worth noting that regardless of how most TLS libraries operate, the
resulting TCP stream is usually optimized. I don't see why our XTLS stream
can't be as optimized. I'd bet that in most cases, the stream will end up
looking exactly the way XTLS currently describes it.

> But you are right, for application data it would be easier to send
> what we get from the tls lib used. So one <message> could result in
> more than one xtls <iq>.

Yes.

> It would be cool to negotiate extra stream parameter for IBB. Besides
> TLS stream compresion comes to my mind.
>
> | <iq type='set'
> | from='romeo (AT) montague (DOT) net/orchard'
> | to='juliet (AT) capulet (DOT) com/balcony'
> | id='inband_1'>
> | <open sid='mySID'
> | block-size='4096'
> | xmlns='http://jabber.org/protocol/ibb'>
> | <feature>urn:xmpp:tmp:tls</feature>
> | <feature>urn:xmpp:tmp:gzip</feature>
> | </open>
> | </iq>
> |
> | <iq type='result'
> | from='juliet (AT) capulet (DOT) com/balcony'
> | to='romeo (AT) montague (DOT) net/orchard'
> | id='inband_1'>
> | <feature>urn:xmpp:tmp:tls</feature>
> | </iq>
>
> In this example Romeo wants tls and gzip compression and Julia answers
> with tls (because she can't do compression). Now the implementation
> knows to start the tls handshake. XTLS should define (like it does
> now) to remove the routing information since we don't need it.

This is an interesting idea, but maybe too far-reaching for now.

> Or (to make it simpler and not support compression) XTLS could define
> that the IBB sid urn:xmpp:tmp:tls means to open an IBB with TLS for
> client to client stanza exchange.

This is probably good enough. You can still get compression through TLS, too,
so it's not so bad.

I'm not sure about overloading the sid. A more-traditional namespaced-element
approach should work just as well:

<iq type='set'
from='romeo (AT) montague (DOT) net/orchard'
to='juliet (AT) capulet (DOT) com/balcony'
id='inband_1'>
<open sid='mySID'
block-size='4096'
xmlns='http://jabber.org/protocol/ibb'>
<xtls xmlns='xtls-ns'/>
</open>
</iq>

-Justin

[Peter Saint-Andre]

On 06/05/2008 9:17 AM, Justin Karneges wrote:
> On Thursday 05 June 2008 2:44 am, Dirk Meyer wrote:
>> Justin Karneges wrote:
>>> XTLS as currently documented is not usable, in my opinion, because it
>>> doesn't treat TLS like a stream. It expects each <iq> exchange to
>>> contain specific TLS frames, which are not things applications normally
>>> know about. You'd have to write a TLS parser to inspect data from your
>>> TLS library, chop them up at TLS frame boundaries, and then wrap them
>>> correctly into <iq>. You may even have some trouble determining the
>>> content of the frames you're sending.
>> Too bad I read this now that I just updated the xtls document. :(
>>
>> So you suggest to handle xtls just like an in-band bytestream with a
>> tls layer on top of it? So unlike the current document you propose
>> that every time your tls lib sends something to a socket you put that
>> into a xmtls iq and send it away? Also for the handshake? I like the
>> way the handshake is now with all messages in one iq stanza.
>
> The handshake could still have all messages in one iq stanza. It's just that
> we wouldn't enforce this behavior.
>
> If a client sends one <iq> stanza containing a 2000 byte payload, great. If a
> client sends 2000 <iq> stanzas each containing a one byte payload, .... not
> so great, but it should be perfectly legal protocol.
>
> It's worth noting that regardless of how most TLS libraries operate, the
> resulting TCP stream is usually optimized. I don't see why our XTLS stream
> can't be as optimized. I'd bet that in most cases, the stream will end up
> looking exactly the way XTLS currently describes it.
>
>> But you are right, for application data it would be easier to send
>> what we get from the tls lib used. So one <message> could result in
>> more than one xtls <iq>.
>
> Yes.
>
>> It would be cool to negotiate extra stream parameter for IBB. Besides
>> TLS stream compresion comes to my mind.
>>
>> | <iq type='set'
>> | from='romeo (AT) montague (DOT) net/orchard'
>> | to='juliet (AT) capulet (DOT) com/balcony'
>> | id='inband_1'>
>> | <open sid='mySID'
>> | block-size='4096'
>> | xmlns='http://jabber.org/protocol/ibb'>
>> | <feature>urn:xmpp:tmp:tls</feature>
>> | <feature>urn:xmpp:tmp:gzip</feature>
>> | </open>
>> | </iq>
>> |
>> | <iq type='result'
>> | from='juliet (AT) capulet (DOT) com/balcony'
>> | to='romeo (AT) montague (DOT) net/orchard'
>> | id='inband_1'>
>> | <feature>urn:xmpp:tmp:tls</feature>
>> | </iq>
>>
>> In this example Romeo wants tls and gzip compression and Julia answers
>> with tls (because she can't do compression). Now the implementation
>> knows to start the tls handshake. XTLS should define (like it does
>> now) to remove the routing information since we don't need it.
>
> This is an interesting idea, but maybe too far-reaching for now.
>
>> Or (to make it simpler and not support compression) XTLS could define
>> that the IBB sid urn:xmpp:tmp:tls means to open an IBB with TLS for
>> client to client stanza exchange.
>
> This is probably good enough. You can still get compression through TLS, too,
> so it's not so bad.
>
> I'm not sure about overloading the sid. A more-traditional namespaced-element
> approach should work just as well:
>
> <iq type='set'
> from='romeo (AT) montague (DOT) net/orchard'
> to='juliet (AT) capulet (DOT) com/balcony'
> id='inband_1'>
> <open sid='mySID'
> block-size='4096'
> xmlns='http://jabber.org/protocol/ibb'>
> <xtls xmlns='xtls-ns'/>
> </open>
> </iq>

It seems that Justin and I are in agreement. :)

Dirk, since you are working on this, perhaps you could send me an
updated XML file and I could check it / clean it up a bit for XSF
conformance / style issues? Then we can ping the XMPP Council about
approving this as a real XEP so that we can have it in source control etc.

Thanks!

Peter

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

[Dirk Meyer]

Peter Saint-Andre wrote:
> On 06/05/2008 9:17 AM, Justin Karneges wrote:
>> I'm not sure about overloading the sid. A more-traditional namespaced-element
>> approach should work just as well:
>>
>> <iq type='set'
>> from='romeo (AT) montague (DOT) net/orchard'
>> to='juliet (AT) capulet (DOT) com/balcony'
>> id='inband_1'>
>> <open sid='mySID'
>> block-size='4096'
>> xmlns='http://jabber.org/protocol/ibb'>
>> <xtls xmlns='xtls-ns'/>
>> </open>
>> </iq>
>
> It seems that Justin and I are in agreement. :)

Ok, not hardcoding the sid. My XML schema knowledge is very limited
but as far as I understand XEP-0047 you can not add an element inside
the open.

> Dirk, since you are working on this, perhaps you could send me an
> updated XML file and I could check it / clean it up a bit for XSF
> conformance / style issues?

I will do that tomorrow. I will replace the hardcoded sid from the
last version I sent you with Justins idea, but I will leave out the
schema because I have no idea how to define xtls inside the open of
IBB. I will also update the text a bit and after that you can clean it
up.

> Then we can ping the XMPP Council about approving this as a real XEP
> so that we can have it in source control etc.

That would be great.


Dirk

--
"I don't read books, but I have friends who do." -Presidential
Candidate George W. Bush

[Peter Saint-Andre]

On 06/05/2008 2:57 PM, Dirk Meyer wrote:
> Peter Saint-Andre wrote:
>> On 06/05/2008 9:17 AM, Justin Karneges wrote:
>>> I'm not sure about overloading the sid. A more-traditional namespaced-element
>>> approach should work just as well:
>>>
>>> <iq type='set'
>>> from='romeo (AT) montague (DOT) net/orchard'
>>> to='juliet (AT) capulet (DOT) com/balcony'
>>> id='inband_1'>
>>> <open sid='mySID'
>>> block-size='4096'
>>> xmlns='http://jabber.org/protocol/ibb'>
>>> <xtls xmlns='xtls-ns'/>
>>> </open>
>>> </iq>
>> It seems that Justin and I are in agreement. :)
>
> Ok, not hardcoding the sid. My XML schema knowledge is very limited
> but as far as I understand XEP-0047 you can not add an element inside
> the open.

Well, we basically allow you to include an extension anywhere (it's the
*extensible* messaging and presence protocol), but we don't always
formally document that in the schemas because the person who makes all
these schemas is lazy (c'st moi).

>> Dirk, since you are working on this, perhaps you could send me an
>> updated XML file and I could check it / clean it up a bit for XSF
>> conformance / style issues?
>
> I will do that tomorrow. I will replace the hardcoded sid from the
> last version I sent you with Justins idea, but I will leave out the
> schema because I have no idea how to define xtls inside the open of
> IBB. I will also update the text a bit and after that you can clean it
> up.

Super.

Peter

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