[Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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 integrated as security layer into Jingle. The protocol can be used for secure end-to-end messages as well as any other Jingle application like file file transfer. URL: http://www.xmpp.org/extensions/inbox/jingle-xtls.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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 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/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
Peter Saint-Andre wrote: > On 06/17/2008 11:31 AM, Dirk Meyer wrote: >> I have some questions about IBB: I should use 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.
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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 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/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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 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.
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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 [EMAIL PROTECTED] advertised in the PTR record. In > | the case of Jingle XML Streams, these SHOULD be the bare JIDs > | (<[EMAIL PROTECTED]> or ) 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/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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.
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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 [EMAIL PROTECTED] advertised in the PTR record. In | the case of Jingle XML Streams, these SHOULD be the bare JIDs | (<[EMAIL PROTECTED]> or ) 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.
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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: | | | | | 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! -
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
> No, with stream:features you have two additional > roundtrips. At the beginning you send and > wait for an answer and an extra stanza with the > . After you restart the stream > and also have a 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 -- Nyx Nyx's Profile: http://www.jabberforum.org/member.php?userid=16996 View this thread: http://www.jabberforum.org/showthread.php?t=238
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
Justin Karneges wrote: > The default namespace is nice, since we needed to qualify the > 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. [...] >xmlns='jabber:client' > xmlns:stream='http://etherx.jabber.org/streams' > from='[EMAIL PROTECTED]' > to='[EMAIL PROTECTED]'> > > M'lady, I would be pleased to make your acquaintance. > 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 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.
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
JabberForum wrote: > ProtoXEP: > > 1. Discover Support > 2. Send XTLS negotiation request, i.e. > 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. > 3. Receive TLS negotiation response, i.e. > 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 and wait for an answer and an extra stanza with the . After you restart the stream and also have a 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.
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
> 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. 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. 3. Receive TLS negotiation response, i.e. 4. Send stanza Both take the same amount of roundtrips between the two entities. -- Nyx Nyx's Profile: http://www.jabberforum.org/member.php?userid=16996 View this thread: http://www.jabberforum.org/showthread.php?t=238
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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 ] > > > > > > > > > > > > If you want that only to re-use your parser, it is an implementation > problem. To re-use a parser just feed to your > parser manually. If you are doing it because it matches the XMPP style > with one large XML document we should go for . I'm happy with > both because, but we should NOT wait for the 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 as the root element: The default namespace is nice, since we needed to qualify the 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 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: M'lady, I would be pleased to make your acquaintance. 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
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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 ] > > > > > If you want that only to re-use your parser, it is an implementation problem. To re-use a parser just feed to your parser manually. If you are doing it because it matches the XMPP style with one large XML document we should go for . I'm happy with both because, but we should NOT wait for the from the peer because it would add an extra roundtrip. Dirk -- UNIX _is_ user friendly - it's just selective about who its friends are!
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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 ] 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 ] 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
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
> 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? -- Nyx Nyx's Profile: http://www.jabberforum.org/member.php?userid=16996 View this thread: http://www.jabberforum.org/showthread.php?t=238
[Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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.
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Justin Karneges wrote: > Most TLS libraries operate as a "black box", passing an opaque stream of > bytes > to the application. I'd suggest making the XEP have a more transparent use > of TLS to match this fact. In other words, rather than saying the first iq > stanza must contain certain explicit TLS constructs (e.g. ClientHello), just > say it can contain any arbitrary TLS data, just like how a real TLS stream > over TCP works. This would allow most off-the-shelf TLS libraries, such as > OpenSSL, to be used with XTLS. Since a stanza stream has TCP-like behavior, > I think we can get away with this. > > Of course, this would mean we'd lose the direct mapping between each > transported stanza and the content within. For example, a single IM may span > multiple transported stanzas, or a single transported stanza may contain > multiple IMs. However, I don't think having a direct mapping buys us much at > all, while having an opaque/transparent transport buys us a *lot*. I agree. Most of the time, you can't control what is going in each TLS packet. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [EMAIL PROTECTED] http://www.argo.es/~jcea/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[EMAIL PROTECTED] _/_/_/_/ _/_/_/_/_/ _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBR1VrXZlgi5GaxT1NAQJ0GwP/RDWzqP/gh4/prc7nVkXsWegDtLyadzgy X1u7ZKcVM8nZcX6ja6PCr2BjbsyJWLxI7otoC226dncFqnj8DxfW8d1EBNAIR6SI wcfT32dC9PsMJWkjIJNqGs42nmKK64rGd0SOhMBvZPaFUrXTXbHrj03gMxVJ5M69 gqhw7BF58aM= =Uqz+ -END PGP SIGNATURE-
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
Tomasz Sterna wrote: > > base_64(TLS-Client-Hello-Message) > > > Damn that we STILL do not have an effective way of transmitting binary > data over XMPP, and we need to resort to BASE64, run it through parser > and serializer... How about converting the non-printable characters to numerical entities? It's common to use when generating text formats with XSLT. &0; should work, too. Stephan
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
On Thursday 01 November 2007 3:23 pm, Tomasz Sterna wrote: > Dnia 01-11-2007, Cz o godzinie 15:13 -0700, Justin Karneges pisze: > > Romeo requests XTLS: > > Juliet agrees: > > Romeo negotiates IBB session: > > > > > id='ibb1' > > to='[EMAIL PROTECTED]/chamber' > > type='set'> > >> block-size='4096' > > xmlns='http://jabber.org/protocol/ibb'/> > > > > We need some way of assigning this IBB to XTLS. > (This could be also related to IBB-FT, etc.) In my example, I was just doing the assignment by having the IBB sid match the XTLS sid. This is the same way that SI (XEP-95) works. -Justin
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
Dnia 01-11-2007, Cz o godzinie 15:13 -0700, Justin Karneges pisze: > Romeo requests XTLS: > Juliet agrees: > Romeo negotiates IBB session: > > id='ibb1' > to='[EMAIL PROTECTED]/chamber' > type='set'> >block-size='4096' > xmlns='http://jabber.org/protocol/ibb'/> > We need some way of assigning this IBB to XTLS. (This could be also related to IBB-FT, etc.) -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
Dnia 01-11-2007, Cz o godzinie 17:25 -0400, Joe Hildebrand pisze: > > > > nul? Not only NULs. CDATA section still needs to be valid UTF-8. So you cannot put any binary chunk inside. And "]]>" string, which might happen in binary data. -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
Justin Karneges wrote: > On Thursday 01 November 2007 12:59 pm, XMPP Extensions Editor wrote: >> 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 semantics of XMPP stanzas >> are preserved by XTLS. >> >> URL: http://www.xmpp.org/extensions/inbox/xtls.html > > I like this idea, but I'd like to see it simplified even further. Here's > some > comments similar to ones I made when the idea was first brought up, and I > think I may have also mentioned this in person at the devcon: > > Most TLS libraries operate as a "black box", passing an opaque stream of > bytes > to the application. I'd suggest making the XEP have a more transparent use > of TLS to match this fact. In other words, rather than saying the first iq > stanza must contain certain explicit TLS constructs (e.g. ClientHello), just > say it can contain any arbitrary TLS data, just like how a real TLS stream > over TCP works. This would allow most off-the-shelf TLS libraries, such as > OpenSSL, to be used with XTLS. Since a stanza stream has TCP-like behavior, > I think we can get away with this. > > Of course, this would mean we'd lose the direct mapping between each > transported stanza and the content within. For example, a single IM may span > multiple transported stanzas, or a single transported stanza may contain > multiple IMs. However, I don't think having a direct mapping buys us much at > all, while having an opaque/transparent transport buys us a *lot*. Well this gets back to what Tomasz said: why not have an opaque data transport? Whether you use it for XTLS or anything else is up to you. /me ponders Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
On Thursday 01 November 2007 12:59 pm, XMPP Extensions Editor wrote: > 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 semantics of XMPP stanzas > are preserved by XTLS. > > URL: http://www.xmpp.org/extensions/inbox/xtls.html I like this idea, but I'd like to see it simplified even further. Here's some comments similar to ones I made when the idea was first brought up, and I think I may have also mentioned this in person at the devcon: Most TLS libraries operate as a "black box", passing an opaque stream of bytes to the application. I'd suggest making the XEP have a more transparent use of TLS to match this fact. In other words, rather than saying the first iq stanza must contain certain explicit TLS constructs (e.g. ClientHello), just say it can contain any arbitrary TLS data, just like how a real TLS stream over TCP works. This would allow most off-the-shelf TLS libraries, such as OpenSSL, to be used with XTLS. Since a stanza stream has TCP-like behavior, I think we can get away with this. Of course, this would mean we'd lose the direct mapping between each transported stanza and the content within. For example, a single IM may span multiple transported stanzas, or a single transported stanza may contain multiple IMs. However, I don't think having a direct mapping buys us much at all, while having an opaque/transparent transport buys us a *lot*. -Justin
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
On Nov 1, 2007, at 5:22 PM, Peter Saint-Andre wrote: nul?
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
Tomasz Sterna wrote: > Dnia 01-11-2007, Cz o godzinie 14:59 -0500, XMPP Extensions Editor > pisze: >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: XMPP Transport Layer Security > > > base_64(TLS-Client-Hello-Message) > > > Damn that we STILL do not have an effective way of transmitting binary > data over XMPP, and we need to resort to BASE64, run it through parser > and serializer... :) smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: XMPP Transport Layer Security
Dnia 01-11-2007, Cz o godzinie 14:59 -0500, XMPP Extensions Editor pisze: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: XMPP Transport Layer Security base_64(TLS-Client-Hello-Message) Damn that we STILL do not have an effective way of transmitting binary data over XMPP, and we need to resort to BASE64, run it through parser and serializer... -- /\_./o__ Tomasz Sterna (/^/(_^^' Xiaoka.com ._.(_.)_ XMPP: [EMAIL PROTECTED]
[Standards] Proposed XMPP Extension: XMPP Transport Layer Security
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 semantics of XMPP stanzas are preserved by XTLS. 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.
