[Standards] Proposed XMPP Extension: XMPP Transport Layer Security

[XMPP Extensions Editor]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: XMPP Transport Layer Security

Abstract: This document specifies the XMPP Transport Layer Security (XTLS) protocol. XTLS, which provides communications privacy for the Extensible Messaging and Presence Protocol (XMPP), enables XMPP applications to communicate in a way that is designed to prevent eavesdropping, tampering, and forgery of XML stanzas. XTLS is based on Transport Layer Security (TLS) and provides equivalent security guarantees. The protocol sends standard TLS handshake data via the existing XMPP extension for In-Band Bytestreams (IBB).

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

The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.

[Nyx]

> The basic idea behind XTLS is that two XMPP entities negotiate
> an encrypted "tunnel" between themselves over XMPP. The tunnel
> is negotiated using standard TLS handshake data, encapsulated
> in In-Band Bytestreams. The entities can then exchange
> TLS-encrypted XMPP stanzas over that tunnel.

What about wrapping all stanzas into a single top-level XML element, so
implementors won't have to start a new XML parser for each stanza?

[Justin Karneges]

On Sunday 08 June 2008 4:23 am, JabberForum wrote:
> > The basic idea behind XTLS is that two XMPP entities negotiate
> > an encrypted "tunnel" between themselves over XMPP. The tunnel
> > is negotiated using standard TLS handshake data, encapsulated
> > in In-Band Bytestreams. The entities can then exchange
> > TLS-encrypted XMPP stanzas over that tunnel.
>
> What about wrapping all stanzas into a single top-level XML element,
> so
> implementors won't have to start a new XML parser for each stanza?

Yes, I agree. As documented, the stream goes something like this:

[ immediate TLS handshake ]
<message/>
<message/>
<message/>

Parsing each message does require a new XML parser instance, or at least some
parser juggling, since the entire stream is not an XML document (in the sense
that we're all used to with XMPP-Core). If, after the TLS handshake
completes, the stream is parsed with an XML parser, you'll get one message
out of it, and then an error as soon as the '<' is encountered of the next
message (document not well formed error?).

I think the original intent with XTLS was to use a new parser instance for the
content of each TLS packet, but this violates the TLS abstraction. Treated
as a stream, we cannot enforce that a particular TLS packet contains an
entire XML document. A single TLS packet might contain many messages, and
one message might be split across many TLS packets.

Better that we change the stream to work like this:

[ immediate TLS handshake ]
<some_root_element>
<message/>
<message/>
<message/>
</some_root_element>

Now a single XML parsing instance can be used for the entire stream, and
message boundaries are determined by the XML parser, not by the IBB/TLS
packetization.

-Justin

[Dirk Meyer]

Justin Karneges wrote:
> I think the original intent with XTLS was to use a new parser instance for the
> content of each TLS packet, but this violates the TLS abstraction.

My original intent was to open a new stream incl. feature handling. I
implemented that and therefor never had the missing root element
problem.

> Treated as a stream, we cannot enforce that a particular TLS packet
> contains an entire XML document. A single TLS packet might contain
> many messages, and one message might be split across many TLS
> packets.
>
> Better that we change the stream to work like this:
>
> [ immediate TLS handshake ]
> <some_root_element>
> <message/>
> <message/>
> <message/>
> </some_root_element>

If you want that only to re-use your parser, it is an implementation
problem. To re-use a parser just feed <some_root_element> to your
parser manually. If you are doing it because it matches the XMPP style
with one large XML document we should go for <stream>. I'm happy with
both because, but we should NOT wait for the <stream> from the peer
because it would add an extra roundtrip.


Dirk

--
UNIX _is_ user friendly - it's just selective about who its friends are!

[Justin Karneges]

On Sunday 08 June 2008 11:57 am, Dirk Meyer wrote:
> Justin Karneges wrote:
> > Treated as a stream, we cannot enforce that a particular TLS packet
> > contains an entire XML document. A single TLS packet might contain
> > many messages, and one message might be split across many TLS
> > packets.
> >
> > Better that we change the stream to work like this:
> >
> > [ immediate TLS handshake ]
> > <some_root_element>
> > <message/>
> > <message/>
> > <message/>
> > </some_root_element>
>
> If you want that only to re-use your parser, it is an implementation
> problem. To re-use a parser just feed <some_root_element> to your
> parser manually. If you are doing it because it matches the XMPP style
> with one large XML document we should go for <stream>. I'm happy with
> both because, but we should NOT wait for the <stream> from the peer
> because it would add an extra roundtrip.

It's true, you could just feed a fake root element to the parser manually. It
would feel somewhat hackish to me if that was the suggested approach to
parsing XTLS content though.

So yeah, for consistency with XMPP, let's go with <stream> as the root
element:

<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='romeo@forza'
to='juliet@pronto'>

The default namespace is nice, since we needed to qualify the <message/>
stanzas anyway. The 'to' and 'from' are a tad superfluous, but maybe we
should consider them for consistency with XEP-174 (Link Local) ? Same for
putting to/from on the message stanzas.

We would leave out the version='1.0' flag though, since there is no
stream:features step. Additionally, we would note in XTLS that there is no
need to wait for the <stream> response from the receiving entity in order to
send messages. This would alleviate the need for a round trip.

So after TLS negotiation completes, you could immediately send this:

<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
from='romeo@forza'
to='juliet@pronto'>
<message from='romeo@forza' to='juliet@pronto'>
<body>M'lady, I would be pleased to make your acquaintance.</body>
</message>

I also think it would be worth having a note about proper stream closure. It
may be comforting to know if the peer has intentionally ended an XTLS
session, to distinguish from a network problem or attack.

-Justin

[Nyx]

> We would leave out the version='1.0' flag though,
> since there is no stream:features step.

I didn't follow the conversation that led to the ProtoXEP in its current form, but what's wrong with doing TLS negotiation in a stream:features step?

ProtoXEP:

1. Discover Support
2. Send XTLS negotiation request, i.e. <xtls/>
3. Receive XTLS negotation response
4. Open IBB
5. Send stanza

With stream:features step:

1. Discover Support
2. Open IBB
3. Send TLS negotiation request, i.e. <starttls/>
3. Receive TLS negotiation response, i.e. <proceed/>
4. Send stanza

Both take the same amount of roundtrips between the two entities.

[Dirk Meyer]

JabberForum wrote:
> ProtoXEP:
>
> 1. Discover Support
> 2. Send XTLS negotiation request, i.e. <xtls/>
> 3. Receive XTLS negotation response
> 4. Open IBB
> 5. Send stanza
>
> With stream:features step:
>
> 1. Discover Support
> 2. Open IBB
> 3. Send TLS negotiation request, i.e. <starttls/>
> 3. Receive TLS negotiation response, i.e. <proceed/>
> 4. Send stanza
>
> Both take the same amount of roundtrips between the two entities.

No, with stream:features you have two additional roundtrips. At the
beginning you send <stream> and wait for an answer and an extra stanza
with the <features>. After <starttls> you restart the stream and also
have a <stream> roundtrip. And well, using the stream idea would not
make it XTLS, because you could open a stream without using starttls
(ok, that makes no sense, but you could do it).

On the other hand (and that is why I used exactly that idea in my
first draft) you could re-use code from link-local messaging. An IBB
stream can be handled like a TCP connection link-local.


Dirk

--
Boat: A hole in the water surrounded by wood.

[Dirk Meyer]

Justin Karneges wrote:
> The default namespace is nice, since we needed to qualify the <message/>
> stanzas anyway. The 'to' and 'from' are a tad superfluous, but maybe we
> should consider them for consistency with XEP-174 (Link Local) ? Same for
> putting to/from on the message stanzas.
[...]
> <stream:stream
> xmlns='jabber:client'
> xmlns:stream='http://etherx.jabber.org/streams'
> from='romeo@forza'
> to='juliet@pronto'>
> <message from='romeo@forza' to='juliet@pronto'>
> <body>M'lady, I would be pleased to make your acquaintance.</body>
> </message>

Since for both XTLS and link-local we do not need the to and the from
in message and iq stanzas. IIRC XEP-0174 says I MUST add them, but we
already have them in the stream. So why not use the FULL jid the the
<stream> and strip all routing information later?

> I also think it would be worth having a note about proper stream
> closure. It may be comforting to know if the peer has intentionally
> ended an XTLS session, to distinguish from a network problem or
> attack.

Sounds ok to me.


Dirk

--
Sorry - yesterday was the deadline for all complaints.

[Nyx]

> No, with stream:features you have two additional
> roundtrips. At the beginning you send <stream> and
> wait for an answer and an extra stanza with the
> <features>. After <starttls> you restart the stream
> and also have a <stream> roundtrip.

Right. There was a discussion not long time ago on how this could be improved. See http://mail.jabber.org/pipermail/standards/2008-February/017934.html

[Dave Cridland]

On Sat Jun 7 00:07:36 2008, XMPP Extensions Editor wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: XMPP Transport Layer Security

Some comments:

1) I like using streams, too, that seems to make perfect sense,
especially given XEP-0174.

2) The TLS handshake section may as well be removed - whether to
request a certificate or not is up to the parties involved - both
parties might want mere confidentiality, and not want certificates
involved at all.

3) It might be reasonable to describe a mechanism for out-of-band (or
in-band informal) channel binding. Something like taking the result
of an HMAC over the TLS hello messages, with "yours" first and
"theirs" after, keyed with a key sent out of band, would do to verify
endpoints (if, of course, the key were sent in such a way that it
were not inetrcepted.)

However, I got talking to Rob McQueen - there's a certain amount of
sense in, instead of describing this in terms of IBB, describing it
in terms of Jingle.

It's possible - and reasonable - to consider an XMPP stream as
content, in which case the TLS becomes a transport (or possibly
attribute of the transport).

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

[Dirk Meyer]

Dave Cridland wrote:
> On Sat Jun 7 00:07:36 2008, XMPP Extensions Editor wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>> Title: XMPP Transport Layer Security
>
> Some comments:
>
> 1) I like using streams, too, that seems to make perfect sense,
> especially given XEP-0174.
[...]
> However, I got talking to Rob McQueen - there's a certain amount of
> sense in, instead of describing this in terms of IBB, describing it
> in terms of Jingle.
>
> It's possible - and reasonable - to consider an XMPP stream as
> content, in which case the TLS becomes a transport (or possibly
> attribute of the transport).

An one hand it is reasonable to use Jingle, I had something like this
is my first draft. On the other hand I would like to reduce the number
of roundtrips needed to set up an XTLS "connection". I would even
consider making XTLS different to remove one roundtrip by adding IBB
open to the xtls iq:

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

I'm not sure if it violates any rules, but IMHO this would be the
fastest way to set up a client-to-client TLS stream. In my scenario I
have many bots talking to each other so I want to reduce the server
load to avoid sending too much stanzas when a new bot comes up.

So we have two choices here:

1. Use jingle and re-use XEP-0174 code.
+ looks reasonable
+ makes it possible to use something else except IBB
- more roundtrips, even more if you try SOCKS5 and it does not work

2. XTLS the way it is now, maybe the shortcut from above
+ faster to set up
- special handling since it is different from XEP-0174

I prefer the second one, but I guess that is something for the XMPP
Cousil to vote for.



Dirk

--
-----------------------------------------------------------------------------
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
-----------------------------------------------------------------------------

[Peter Saint-Andre]

On 06/09/2008 9:50 AM, Dave Cridland wrote:
> On Sat Jun 7 00:07:36 2008, XMPP Extensions Editor wrote:
>> The XMPP Extensions Editor has received a proposal for a new XEP.
>>
>> Title: XMPP Transport Layer Security
>
> Some comments:
>
> 1) I like using streams, too, that seems to make perfect sense,
> especially given XEP-0174.
>
> 2) The TLS handshake section may as well be removed - whether to request
> a certificate or not is up to the parties involved - both parties might
> want mere confidentiality, and not want certificates involved at all.
>
> 3) It might be reasonable to describe a mechanism for out-of-band (or
> in-band informal) channel binding. Something like taking the result of
> an HMAC over the TLS hello messages, with "yours" first and "theirs"
> after, keyed with a key sent out of band, would do to verify endpoints
> (if, of course, the key were sent in such a way that it were not
> inetrcepted.)

I've been thinking about something like that for regular old TLS over
direct XML streams (RFC 3920) because presumably that would give you a
shared secret that you could use for certain interesting use cases
(e.g., hop check), but I have not given much thought to that yet. And
consider it off-topic for this thread. :)

> However, I got talking to Rob McQueen - there's a certain amount of
> sense in, instead of describing this in terms of IBB, describing it in
> terms of Jingle.
>
> It's possible - and reasonable - to consider an XMPP stream as content,
> in which case the TLS becomes a transport (or possibly attribute of the
> transport).

Part of the idea behind XTLS is that you might want to use the XTLS
"tunnel" for all e2e communications with another party. In particular,
you might want to use that tunnel so that you don't expose your IP
addresses during a Jingle negotiation (e.g., if you did XTLS over
ICE-TCP or SOCKS5). So forcing XTLS to depend on Jingle might defeat the
purpose. What transport would be used if we described XTLS in terms of
Jingle, and might you expose personally identifying information in that way?

Peter

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

[Peter Saint-Andre]

On 06/09/2008 11:09 AM, Peter Saint-Andre wrote:
> On 06/09/2008 9:50 AM, Dave Cridland wrote:
>
>> However, I got talking to Rob McQueen - there's a certain amount of
>> sense in, instead of describing this in terms of IBB, describing it in
>> terms of Jingle.
>>
>> It's possible - and reasonable - to consider an XMPP stream as content,
>> in which case the TLS becomes a transport (or possibly attribute of the
>> transport).
>
> Part of the idea behind XTLS is that you might want to use the XTLS
> "tunnel" for all e2e communications with another party. In particular,
> you might want to use that tunnel so that you don't expose your IP
> addresses during a Jingle negotiation (e.g., if you did XTLS over
> ICE-TCP or SOCKS5). So forcing XTLS to depend on Jingle might defeat the
> purpose. What transport would be used if we described XTLS in terms of
> Jingle, and might you expose personally identifying information in that way?

I just had a chat with Justin Karneges about XTLS. I'm now convinced
that it's best to follow the approach outlined above -- use Jingle to
negotiate an e2e stream that is transported via a reliable transport
mechanism such as SOCKS5 Bytestreams, IBB, reliable UDP, or whatever
else people come up with. I am currently revising the proposal along
those lines and will post to the list when I'm finished with the edits.

Peter

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

[Peter Saint-Andre]

On 06/13/2008 1:10 PM, Peter Saint-Andre wrote:
> On 06/09/2008 11:09 AM, Peter Saint-Andre wrote:
>> On 06/09/2008 9:50 AM, Dave Cridland wrote:
>>
>>> However, I got talking to Rob McQueen - there's a certain amount of
>>> sense in, instead of describing this in terms of IBB, describing it in
>>> terms of Jingle.
>>>
>>> It's possible - and reasonable - to consider an XMPP stream as content,
>>> in which case the TLS becomes a transport (or possibly attribute of the
>>> transport).
>> Part of the idea behind XTLS is that you might want to use the XTLS
>> "tunnel" for all e2e communications with another party. In particular,
>> you might want to use that tunnel so that you don't expose your IP
>> addresses during a Jingle negotiation (e.g., if you did XTLS over
>> ICE-TCP or SOCKS5). So forcing XTLS to depend on Jingle might defeat the
>> purpose. What transport would be used if we described XTLS in terms of
>> Jingle, and might you expose personally identifying information in that way?
>
> I just had a chat with Justin Karneges about XTLS. I'm now convinced
> that it's best to follow the approach outlined above -- use Jingle to
> negotiate an e2e stream that is transported via a reliable transport
> mechanism such as SOCKS5 Bytestreams, IBB, reliable UDP, or whatever
> else people come up with. I am currently revising the proposal along
> those lines and will post to the list when I'm finished with the edits.

OK, while working on this I realized that the most modular way to spec
this out is as follows:

1. We modify XEP-0174 so it just defines _presence._tcp as a discovery
mechanism, as a result of which you have an IP address and port that you
can use for a direct TCP connection that functions as a transport for an
e2e XML stream.

2. We split the e2e XML streams stuff out from XEP-0174 into a new
"e2e-streams" spec, which defines how you use whatever reliable
transport is close to hand (direct TCP connection, IBB, SOCKS5, ice-tcp,
etc.) as the transport for an e2e XML stream (this can be unencrypted as
all XEP-0174 implementations do now, or upgraded to encrypted using
STARTTLS, which is what we'd recommend -- but this way it is
backwards-compatible and enables code reuse).

3. The current XTLS spec morphs into a new "Jingle-xmpp" spec that
defines a Jingle application type for an XMPP session (as defined in
XEP-streams), where that application type can use IBB, SOCKS5, ice-tcp,
or any other reliable transport.

So this is the way I'll proceed.

Peter

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

[Dirk Meyer]

Peter Saint-Andre wrote:
> 1. We modify XEP-0174 so it just defines _presence._tcp as a discovery
> mechanism, as a result of which you have an IP address and port that you
> can use for a direct TCP connection that functions as a transport for an
> e2e XML stream.
>
> 2. We split the e2e XML streams stuff out from XEP-0174 into a new
> "e2e-streams" spec, which defines how you use whatever reliable
> transport is close to hand (direct TCP connection, IBB, SOCKS5, ice-tcp,
> etc.) as the transport for an e2e XML stream (this can be unencrypted as
> all XEP-0174 implementations do now, or upgraded to encrypted using
> STARTTLS, which is what we'd recommend -- but this way it is
> backwards-compatible and enables code reuse).

It should get a note about clientCert requests.

> 3. The current XTLS spec morphs into a new "Jingle-xmpp" spec that
> defines a Jingle application type for an XMPP session (as defined in
> XEP-streams), where that application type can use IBB, SOCKS5, ice-tcp,
> or any other reliable transport.

Sounds ok to me. Funny thing is that XTLS gets closer again to my
first idea (except that I did not used jingle). If you need some help
writing 2. or 3. give me a call. I will be away for the weekend but
could help you out on sunday evening (which will be the whole sunday
in your timezone).


Dirk

P.S.: Too bad I implemented the current XTLS today for testing

--
[X] <-- nail here for new monitor

[Peter Saint-Andre]

On 06/13/2008 3:12 PM, Dirk Meyer wrote:
> Peter Saint-Andre wrote:
>> 1. We modify XEP-0174 so it just defines _presence._tcp as a discovery
>> mechanism, as a result of which you have an IP address and port that you
>> can use for a direct TCP connection that functions as a transport for an
>> e2e XML stream.
>>
>> 2. We split the e2e XML streams stuff out from XEP-0174 into a new
>> "e2e-streams" spec, which defines how you use whatever reliable
>> transport is close to hand (direct TCP connection, IBB, SOCKS5, ice-tcp,
>> etc.) as the transport for an e2e XML stream (this can be unencrypted as
>> all XEP-0174 implementations do now, or upgraded to encrypted using
>> STARTTLS, which is what we'd recommend -- but this way it is
>> backwards-compatible and enables code reuse).
>
> It should get a note about clientCert requests.

Correct.

>> 3. The current XTLS spec morphs into a new "Jingle-xmpp" spec that
>> defines a Jingle application type for an XMPP session (as defined in
>> XEP-streams), where that application type can use IBB, SOCKS5, ice-tcp,
>> or any other reliable transport.
>
> Sounds ok to me. Funny thing is that XTLS gets closer again to my
> first idea (except that I did not used jingle). If you need some help
> writing 2. or 3. give me a call. I will be away for the weekend but
> could help you out on sunday evening (which will be the whole sunday
> in your timezone).

I hope to finish the work today, but we'll see if I'm successful...

> P.S.: Too bad I implemented the current XTLS today for testing

Ouch. You are too fast. :(

If we can get this spec'd out soon, perhaps we'll even be able to hold a
bit of an interop event + hackfest at the XMPP Summit July 21 and 22:

http://www.xmpp.org/summit/summit5.shtml

Peter

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

[Peter Saint-Andre]

On 06/13/2008 3:33 PM, Peter Saint-Andre wrote:
> On 06/13/2008 3:12 PM, Dirk Meyer wrote:
>> Peter Saint-Andre wrote:
>>> 1. We modify XEP-0174 so it just defines _presence._tcp as a discovery
>>> mechanism, as a result of which you have an IP address and port that you
>>> can use for a direct TCP connection that functions as a transport for an
>>> e2e XML stream.
>>>
>>> 2. We split the e2e XML streams stuff out from XEP-0174 into a new
>>> "e2e-streams" spec, which defines how you use whatever reliable
>>> transport is close to hand (direct TCP connection, IBB, SOCKS5, ice-tcp,
>>> etc.) as the transport for an e2e XML stream (this can be unencrypted as
>>> all XEP-0174 implementations do now, or upgraded to encrypted using
>>> STARTTLS, which is what we'd recommend -- but this way it is
>>> backwards-compatible and enables code reuse).
>> It should get a note about clientCert requests.
>
> Correct.
>
>>> 3. The current XTLS spec morphs into a new "Jingle-xmpp" spec that
>>> defines a Jingle application type for an XMPP session (as defined in
>>> XEP-streams), where that application type can use IBB, SOCKS5, ice-tcp,
>>> or any other reliable transport.
>> Sounds ok to me. Funny thing is that XTLS gets closer again to my
>> first idea (except that I did not used jingle). If you need some help
>> writing 2. or 3. give me a call. I will be away for the weekend but
>> could help you out on sunday evening (which will be the whole sunday
>> in your timezone).
>
> I hope to finish the work today, but we'll see if I'm successful...

Here is an early version of the Jingle-streams spec:

http://www.xmpp.org/extensions/inbox/jingle-streams.html

Next I'll copy the e2e-streams stuff from XEP-0174 into a new spec.

Peter

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

[Peter Saint-Andre]

On 06/13/2008 3:45 PM, Peter Saint-Andre wrote:

> Here is an early version of the Jingle-streams spec:
>
> http://www.xmpp.org/extensions/inbox/jingle-streams.html
>
> Next I'll copy the e2e-streams stuff from XEP-0174 into a new spec.

http://www.xmpp.org/extensions/inbox/e2e-streams.html

Peter

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

[Dirk Meyer]

Peter Saint-Andre wrote:
> On 06/13/2008 3:45 PM, Peter Saint-Andre wrote:
>
>> Here is an early version of the Jingle-streams spec:
>>
>> http://www.xmpp.org/extensions/inbox/jingle-streams.html
>>
>> Next I'll copy the e2e-streams stuff from XEP-0174 into a new spec.
>
> http://www.xmpp.org/extensions/inbox/e2e-streams.html

| In accordance with rfc3921bis [5], the initial stream header SHOULD
| include the 'to' and 'from' attributes. In the case of XEP-0174, these
| SHOULD be the username@machine-name advertised in the PTR record. In
| the case of Jingle XML Streams, these SHOULD be the bare JIDs
| (<localpart (AT) domain (DOT) tld> or <domain.tld>) of the entities as
| communicated via XMPP.

I would prefer the full JID in the stream header. In my use case two
different bots of the same user talk to each other. In that case it
would be very helpful to use the full JID. The same is true for
XEP-0174. If I have different set-top boxes in my home network with
the same software I need a way to keep them apart.


Dirk

--
A seminar on time travel will be held in two weeks ago.

[Dirk Meyer]

Peter Saint-Andre wrote:
>> P.S.: Too bad I implemented the current XTLS today for testing
>
> Ouch. You are too fast. :(

Doesn't matter. I also had my previous coded so it is similar to the
new specs. Except that I have no jingle implementation yet.

> If we can get this spec'd out soon, perhaps we'll even be able to hold a
> bit of an interop event + hackfest at the XMPP Summit July 21 and 22:

I will have to talk to my boss if the university will pay for it. :)

Dirk

--
The trouble with work is... it's so daily.

[Peter Saint-Andre]

On 06/14/2008 3:50 AM, Dirk Meyer wrote:
> Peter Saint-Andre wrote:
>> On 06/13/2008 3:45 PM, Peter Saint-Andre wrote:
>>
>>> Here is an early version of the Jingle-streams spec:
>>>
>>> http://www.xmpp.org/extensions/inbox/jingle-streams.html
>>>
>>> Next I'll copy the e2e-streams stuff from XEP-0174 into a new spec.
>> http://www.xmpp.org/extensions/inbox/e2e-streams.html
>
> | In accordance with rfc3921bis [5], the initial stream header SHOULD
> | include the 'to' and 'from' attributes. In the case of XEP-0174, these
> | SHOULD be the username@machine-name advertised in the PTR record. In
> | the case of Jingle XML Streams, these SHOULD be the bare JIDs
> | (<localpart (AT) domain (DOT) tld> or <domain.tld>) of the entities as
> | communicated via XMPP.
>
> I would prefer the full JID in the stream header. In my use case two
> different bots of the same user talk to each other. In that case it
> would be very helpful to use the full JID. The same is true for
> XEP-0174. If I have different set-top boxes in my home network with
> the same software I need a way to keep them apart.

There are two ways to handle this:

1. Full JID case: allow multiple simultaneous streams between entities,
one for each communication session.

2. Bare JID case: use one stream between entities and bind multiple
resources to the stream if necessary (see rfc3920bis).

Right now, XEP-0174 uses bare JIDs for the 'to' and 'from' addresses on
the stream headers, so it seems that it might follow #2, but AFAIK no
clients implement binding of multiple resources. I don't know if any
clients currently rely on the 'to' and 'from' in XEP-0174, so I think it
would be safe to modify XEP-0174 to use full JIDs, not bare JIDs (or use
either). Given that an e2e stream is between two endpoints, using full
JIDs seems like it might be more appropriate.

Peter

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

[Peter Saint-Andre]

On 06/14/2008 4:00 AM, Dirk Meyer wrote:
> Peter Saint-Andre wrote:
>>> P.S.: Too bad I implemented the current XTLS today for testing
>> Ouch. You are too fast. :(
>
> Doesn't matter. I also had my previous coded so it is similar to the
> new specs. Except that I have no jingle implementation yet.

OK cool.

>> If we can get this spec'd out soon, perhaps we'll even be able to hold a
>> bit of an interop event + hackfest at the XMPP Summit July 21 and 22:
>
> I will have to talk to my boss if the university will pay for it. :)

The XSF may be able to provide some assistance to developers who
implement XTLS (or whatever we will call it now) -- I'm working with the
XSF Board of Directors about that. End-to-end encryption is a big
priority for us (though you'd never know it from all our failed attempts
in the past...).

Peter

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

[Dirk Meyer]

Peter Saint-Andre wrote:
> On 06/14/2008 4:00 AM, Dirk Meyer wrote:
>> Peter Saint-Andre wrote:
>>>> P.S.: Too bad I implemented the current XTLS today for testing
>>> Ouch. You are too fast. :(
>>
>> Doesn't matter. I also had my previous coded so it is similar to the
>> new specs. Except that I have no jingle implementation yet.
>
> OK cool.

I have some working code. It is not very error tolerant and only uses
IBB (my implementation has no SOCKS5 yet) but it works. It is slower
(no surprise) than the "old" XTLS but I guess it partly is my fault. I
use iq for IBB (no idea if my server supports AMP) and I guess
ejabberd is slowing me down (the server is in the same network with a
GBit connection). I need to do some cleanups in my code before
releasing the source for others to test. :)

I have some questions about IBB: I should use <message> if I have
AMP. But to detect that I need to ask both servers involved and the
peer if they all support it, right? How do I ask the servers? I get a
not-allowed from ejabberd when sending a disco-query.

>>> If we can get this spec'd out soon, perhaps we'll even be able to hold a
>>> bit of an interop event + hackfest at the XMPP Summit July 21 and 22:
>>
>> I will have to talk to my boss if the university will pay for it. :)
>
> The XSF may be able to provide some assistance to developers who
> implement XTLS (or whatever we will call it now) -- I'm working with the
> XSF Board of Directors about that. End-to-end encryption is a big
> priority for us (though you'd never know it from all our failed attempts
> in the past...).

It is not only about the money, there is a project deadline at the end
of July. If they let me go to the Summit it would be only for the two
days (no extra vacation). A very long trip for just two days. Do you
also meet at the IETF? Dublin is much easier for me (and not in
July).


Dirk

--
The trouble with work is... it's so daily.

[Peter Saint-Andre]

On 06/17/2008 11:31 AM, Dirk Meyer wrote:
> Peter Saint-Andre wrote:
>> On 06/14/2008 4:00 AM, Dirk Meyer wrote:
>>> Peter Saint-Andre wrote:
>>>>> P.S.: Too bad I implemented the current XTLS today for testing
>>>> Ouch. You are too fast. :(
>>> Doesn't matter. I also had my previous coded so it is similar to the
>>> new specs. Except that I have no jingle implementation yet.
>> OK cool.
>
> I have some working code. It is not very error tolerant and only uses
> IBB (my implementation has no SOCKS5 yet) but it works. It is slower
> (no surprise) than the "old" XTLS but I guess it partly is my fault. I
> use iq for IBB (no idea if my server supports AMP) and I guess
> ejabberd is slowing me down (the server is in the same network with a
> GBit connection). I need to do some cleanups in my code before
> releasing the source for others to test. :)
>
> I have some questions about IBB: I should use <message> if I have
> AMP. But to detect that I need to ask both servers involved and the
> peer if they all support it, right?

Yeah. AMP is not yet widely deployed at all. Better to use IQ for now, I
think.

> How do I ask the servers? I get a
> not-allowed from ejabberd when sending a disco-query.

That error doesn't sound right.

>>>> If we can get this spec'd out soon, perhaps we'll even be able to hold a
>>>> bit of an interop event + hackfest at the XMPP Summit July 21 and 22:
>>> I will have to talk to my boss if the university will pay for it. :)
>> The XSF may be able to provide some assistance to developers who
>> implement XTLS (or whatever we will call it now) -- I'm working with the
>> XSF Board of Directors about that. End-to-end encryption is a big
>> priority for us (though you'd never know it from all our failed attempts
>> in the past...).
>
> It is not only about the money, there is a project deadline at the end
> of July. If they let me go to the Summit it would be only for the two
> days (no extra vacation). A very long trip for just two days. Do you
> also meet at the IETF? Dublin is much easier for me (and not in
> July).

We'll have another XMPP Summit at FOSDEM 2009 in Brussels. I was just
hoping we could put together an XTLS hackathon in July, but we could do
that online, too.

Peter

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

[Dirk Meyer]

Peter Saint-Andre wrote:
> On 06/17/2008 11:31 AM, Dirk Meyer wrote:
>> I have some questions about IBB: I should use <message> if I have
>> AMP. But to detect that I need to ask both servers involved and the
>> peer if they all support it, right?
>
> Yeah. AMP is not yet widely deployed at all. Better to use IQ for now, I
> think.

Too bad. IMHO AMP and Stanza Acknowledgements are a must have for
reliable communication.

> We'll have another XMPP Summit at FOSDEM 2009 in Brussels. I was just
> hoping we could put together an XTLS hackathon in July, but we could do
> that online, too.

So that is a "No" to an IETF meeting. Too bad, Dublin is nice :).
Brussels sound much better for me and if someone else implements this,
I'm ready for an online session. I have XTLS (the old version) and
Jingle-Streams implemented -- at least opening and using the stream,
my implementation does not like such a stream ending :)


Dirk

--
What happens if a big asteroid hits the Earth? Judging from realistic
simulations involving a sledge hammer and a common laboratory frog, we
can assume it will be pretty bad.

[Peter Saint-Andre]

On 06/18/2008 2:14 PM, Dirk Meyer wrote:
> Peter Saint-Andre wrote:
>> On 06/17/2008 11:31 AM, Dirk Meyer wrote:
>>> I have some questions about IBB: I should use <message> if I have
>>> AMP. But to detect that I need to ask both servers involved and the
>>> peer if they all support it, right?
>> Yeah. AMP is not yet widely deployed at all. Better to use IQ for now, I
>> think.
>
> Too bad. IMHO AMP and Stanza Acknowledgements are a must have for
> reliable communication.

Well, for IBB you have IQ, so use it. :)

>> We'll have another XMPP Summit at FOSDEM 2009 in Brussels. I was just
>> hoping we could put together an XTLS hackathon in July, but we could do
>> that online, too.
>
> So that is a "No" to an IETF meeting. Too bad, Dublin is nice :).

There is no XMPP Working Group at the IETF and hasn't been since 2004.
That doesn't mean we might not form an "XMPP Extensions" WG of some kind
in the future (e.g., to formalize things like disco, muc, and pubsub).

> Brussels sound much better for me and if someone else implements this,
> I'm ready for an online session. I have XTLS (the old version) and
> Jingle-Streams implemented -- at least opening and using the stream,
> my implementation does not like such a stream ending :)

I hope we'll have more implementations in the near future, as in the
next few months.

Peter

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