Re: [Standards] rfc3921bis: subscribing to a full JID
On 06/05/2008 4:08 PM, Justin Karneges wrote: > On Thursday 05 June 2008 2:39 pm, Peter Saint-Andre wrote: >> Should we allow subscriptions to a full JID instead of a bare JID? >> >> For example: >> >> > to='[EMAIL PROTECTED]/resource' >> type='subscribe'/> >> >> I know people have said there are legitimate scenarios when you might >> want to do that, but I've never found them compelling. > > Historically this has always been allowed, and in fact there are some > situations where it has been required. For example, transports that > use "/registered" for subscriptions would depend on this, and they may even > still be deployed. > > Like my other mail, "MUST NOT" is too strong then. We could go with "SHOULD > NOT" if we want to attempt to deprecate the feature. I think so too. I think it's probably enough to actively discourage this in clients. > I agree that in general this ability is mostly confusing as heck. It's kind > of an interesting geek feature, but it shouldn't be required by anyone to get > anything done. Agreed. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] rfc3921bis: subscribing to a full JID
On 06/05/2008 6:06 PM, anders conbere wrote: > On Thu, Jun 5, 2008 at 2:39 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: >> Should we allow subscriptions to a full JID instead of a bare JID? >> >> For example: >> >> > to='[EMAIL PROTECTED]/resource' >> type='subscribe'/> > > This would only be interesting to me if we had contextual rosters > based on resources What are those? smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] rfc3921bis: subscribing to a full JID
On Thu, Jun 5, 2008 at 2:39 PM, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > Should we allow subscriptions to a full JID instead of a bare JID? > > For example: > > to='[EMAIL PROTECTED]/resource' > type='subscribe'/> This would only be interesting to me if we had contextual rosters based on resources ~ Anders > > I know people have said there are legitimate scenarios when you might > want to do that, but I've never found them compelling. > > However, if we say that you MUST NOT subscribe to a full JID, then that > rule needs to be enforced somewhere. Here are the options: > > 1. Enforced by user's server. (See below.) > > 2. Enforced by contact's server. > > In this case, the contact's server will return a presence error: > > to='[EMAIL PROTECTED]' > type='error'> > > > > > > (Or perhaps ?) > > Because the error is sent to [EMAIL PROTECTED] (bare JID), would it be > handled by the user's server? I think so. Which means that... > > Both (1) and (2) imply that the user's server needs to inform the client > that a problem occurred with the subscription request. But how? Would it > return a presence error to the user's client? Presence errors are rare > (perhaps even nonexistent) right now -- instead we use unsubscribe and > unsubscribed in rfc3921bis. So I don't know how existing clients will > handle presence errors. > > I don't have a strong preference between enforcing this at the user's > server or the contact's server, although I lean toward user's server > (because the user's server is the one that would need to deal with all > the complexities of full-JID subscriptions -- but note that this has an > impact on the contact's server as well if the user's server starts to > send presence probes to full JIDs there, so I see no harm in enforcing > this in both places). > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > >
Re: [Standards] rfc3921bis: subscribing to a full JID
On Thursday 05 June 2008 2:39 pm, Peter Saint-Andre wrote: > Should we allow subscriptions to a full JID instead of a bare JID? > > For example: > >to='[EMAIL PROTECTED]/resource' > type='subscribe'/> > > I know people have said there are legitimate scenarios when you might > want to do that, but I've never found them compelling. Historically this has always been allowed, and in fact there are some situations where it has been required. For example, transports that use "/registered" for subscriptions would depend on this, and they may even still be deployed. Like my other mail, "MUST NOT" is too strong then. We could go with "SHOULD NOT" if we want to attempt to deprecate the feature. I agree that in general this ability is mostly confusing as heck. It's kind of an interesting geek feature, but it shouldn't be required by anyone to get anything done. -Justin
[Standards] rfc3921bis: subscribing to a full JID
Should we allow subscriptions to a full JID instead of a bare JID? For example: I know people have said there are legitimate scenarios when you might want to do that, but I've never found them compelling. However, if we say that you MUST NOT subscribe to a full JID, then that rule needs to be enforced somewhere. Here are the options: 1. Enforced by user's server. (See below.) 2. Enforced by contact's server. In this case, the contact's server will return a presence error: (Or perhaps ?) Because the error is sent to [EMAIL PROTECTED] (bare JID), would it be handled by the user's server? I think so. Which means that... Both (1) and (2) imply that the user's server needs to inform the client that a problem occurred with the subscription request. But how? Would it return a presence error to the user's client? Presence errors are rare (perhaps even nonexistent) right now -- instead we use unsubscribe and unsubscribed in rfc3921bis. So I don't know how existing clients will handle presence errors. I don't have a strong preference between enforcing this at the user's server or the contact's server, although I lean toward user's server (because the user's server is the one that would need to deal with all the complexities of full-JID subscriptions -- but note that this has an impact on the contact's server as well if the user's server starts to send presence probes to full JIDs there, so I see no harm in enforcing this in both places). Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] New XMPP Use Case: Private Media Networks
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: >>> >>> >> from='[EMAIL PROTECTED]/orchard' >>> to='[EMAIL PROTECTED]/balcony' >>> id='inband_1'> >>> >> block-size='4096' >>> xmlns='http://jabber.org/protocol/ibb'> >>> >>> >>> >> 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/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] rfc3921bis: multiple items in roster set
I'm reviewing a bunch of old messages about rfc3921bis, so expect a few posts to the list. Here is the first one... Currently, some clients include multiple items in a roster set to complete certain use cases, for example to rename a group: NewGroupName NewGroupName However, Rule 1 in Section 2.1.3 of rfc3921bis states: "The element MUST contain one and only one element." Would it break anything to allow multiple items in a roster set? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] New XMPP Use Case: Private Media Networks
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: >> >> > from='[EMAIL PROTECTED]/orchard' >> to='[EMAIL PROTECTED]/balcony' >> id='inband_1'> >> > block-size='4096' >> xmlns='http://jabber.org/protocol/ibb'> >> >> >> > > 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
[Standards] IO DATA v. 0.0.4
Johannes Wagener has sent me version 0.0.4 of the IO DATA proposal: http://www.xmpp.org/extensions/inbox/io-data.html At the next XMPP Council meeting I will request publication of this proposal as a XEP. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
[Standards] UPDATED: XEP-0234 (Jingle File Transfer)
Version 0.5 of XEP-0234 (Jingle File Transfer) has been released. Abstract: This specification defines a Jingle application type for transferring files between two entities. The protocol provides a modular framework that enables the exchange of information about the file to be transferred as well as the negotiation of parameters such as the transport to be used. Changelog: Modified fallback scenario to use content-replace action during pending state. (psa) Diff: http://is.gd/rFv URL: http://www.xmpp.org/extensions/xep-0234.html
Re: [Standards] Hop Check reconnects
On 06/05/2008 12:11 PM, Maciek Niedzielski wrote: > Peter Saint-Andre wrote: >> On 06/15/2007 4:46 AM, Dave Cridland wrote: >>> First off, Ian's point 4 above seems to be on the mark - we don't care >>> if the hops were encrypted when we asked, we care if they're >>> encrypted now. >> I hate to suggest this because people in the badattitude room will >> snicker at me (you know who you are!), but I suppose we could use PEP >> for this... :P > That's my line :) Yeah yeah yeah. :P In fact I think it's better to use presence for this use case! Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Jingle: content-replace during PENDING state
On 05/28/2008 12:44 PM, Robert McQueen wrote: > Peter Saint-Andre wrote: >> Therefore I think the content-replace action is unnecessary in XEP-0176 >> (since nomination in the Jingle ICE-UDP transport will also occur over >> STUN and does not need to happen in the signalling channel). >> >> Unless there are objections, I will update XEP-0176 accordingly (a usage >> inherited by some of the examples in XEP-0167 and XEP-0180, which will >> be harmonized with the modified XEP-0176). > > +1 from me. My gut feeling is that content-replace is more of a content > apocalypse in terms of implementations. I don't think it's reasonable to > expect people to have to diff content descriptions and transports in > normal operation - it should have a similar semantic/behaviour as > content-remove and content-add delivered simultaneously. Hmm. I agree that content-replace should be equivalent to simultaneous content-remove and content-add. I thought it was, but perhaps I was wrong. :) However, it seems that we need content-replace during PENDING in order to handle certain fallback use cases (see the thread on Jingle file transfer). I am going to update XEP-0234 to use this model so that we can see if it will solve the fallback problem in a more elegant way. If so, I may request that we allow content-replace during PENDING. More soon. :) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Hop Check reconnects
Peter Saint-Andre wrote: On 06/15/2007 4:46 AM, Dave Cridland wrote: First off, Ian's point 4 above seems to be on the mark - we don't care if the hops were encrypted when we asked, we care if they're encrypted now. I hate to suggest this because people in the badattitude room will snicker at me (you know who you are!), but I suppose we could use PEP for this... :P That's my line :) -- Maciek xmpp:[EMAIL PROTECTED]
Re: [Standards] Hop Check reconnects
Seriously delayed reply. :) On 06/15/2007 4:46 AM, Dave Cridland wrote: > On Fri Jun 15 10:50:52 2007, Ian Paterson wrote: >> 4. If my server's encrypted connections with my contact's server go >> down and are replaced by unencrypted connections. > > Reading through XEP-0219, I'm left wondering about a few things. > > First off, Ian's point 4 above seems to be on the mark - we don't care > if the hops were encrypted when we asked, we care if they're encrypted now. Agreed. I hate to suggest this because people in the badattitude room will snicker at me (you know who you are!), but I suppose we could use PEP for this... :P > Second, I'm not sure we normally care which links are not encrypted - we > care if all of them are or not. The mechanism described in XEP-0219 > might help an experienced user detirmine where the fault lay, and can be > used to answer the question, but it's a lot of information to go through > to answer a boolean question. The problem is, who answers this question? Is it something that I depend on my server to answer (if I trust it enough, blah blah blah)? I suppose so. > Thirdly, some of this information ought to be kept private. Something is > nagging me that including the SASL mechanism used for authentication is > probably not a good idea. I think there's probably more than the obvious > case that knowing a hop uses no mutual authentication allows an attacker > to scan for potential spoofing victims. I'm pretty sure that the network > addresses should be omitted, too. I think you're right. > I had a quick chat with Ian about whether we might distribute encryption > information in presence - such that servers implementing the extension > would alter presence stanzas en-route to contain an overall indicator of > the encryption state of the path - but not only does Ian disagree, but > I've also realized that this doesn't solve the issue either. I think > some mechanism for maintaining a path-state database is useful, though, > and to my mind, adding this information to presence remains the obvious > way to do it. And, again, would my server add that on incoming presence it receives from people in my roster? > But we want to also know that a stanza sent to a specific destination > will only go across encrypted links, and the only way I can see to do > that would be to attach that requirement to the stanza itself, > presuambly as an attribute on the stanza. > > Neither fiddling with presence, nor new top-level stanza attributes, are > particularly popular, of course, with good reason, but I think the need > might justofy the cost in this instance. Adding an extension to presence is not prima facie evil. So if I ask my server to track this information for a contact, it would add a signed extension to presence it receives from the contact telling me whether the full path is encrypted or not (based on information it has from the contact's server). /me ponders Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] New XMPP Use Case: Private Media Networks
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 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 . 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 stanza containing a 2000 byte payload, great. If > a > client sends 2000 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 could result in >> more than one xtls . > > Yes. > >> It would be cool to negotiate extra stream parameter for IBB. Besides >> TLS stream compresion comes to my mind. >> >> | > | from='[EMAIL PROTECTED]/orchard' >> | to='[EMAIL PROTECTED]/balcony' >> | id='inband_1'> >> | > | block-size='4096' >> | xmlns='http://jabber.org/protocol/ibb'> >> | urn:xmpp:tmp:tls >> | urn:xmpp:tmp:gzip >> | >> | >> | >> | > | from='[EMAIL PROTECTED]/balcony' >> | to='[EMAIL PROTECTED]/orchard' >> | id='inband_1'> >> | urn:xmpp:tmp:tls >> | >> >> 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: > > from='[EMAIL PROTECTED]/orchard' > to='[EMAIL PROTECTED]/balcony' > id='inband_1'> >block-size='4096' > xmlns='http://jabber.org/protocol/ibb'> > > > 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/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] New XMPP Use Case: Private Media Networks
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 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 . 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 stanza containing a 2000 byte payload, great. If a client sends 2000 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 could result in > more than one xtls . Yes. > It would be cool to negotiate extra stream parameter for IBB. Besides > TLS stream compresion comes to my mind. > > | | from='[EMAIL PROTECTED]/orchard' > | to='[EMAIL PROTECTED]/balcony' > | id='inband_1'> > || block-size='4096' > | xmlns='http://jabber.org/protocol/ibb'> > | urn:xmpp:tmp:tls > | urn:xmpp:tmp:gzip > | > | > | > | | from='[EMAIL PROTECTED]/balcony' > | to='[EMAIL PROTECTED]/orchard' > | id='inband_1'> > | urn:xmpp:tmp:tls > | > > 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: -Justin
Re: [Standards] New XMPP Use Case: Private Media Networks
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 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 . 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 could result in > more than one xtls . 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 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. > > | | from='[EMAIL PROTECTED]/orchard' > | to='[EMAIL PROTECTED]/balcony' > | id='inband_1'> > || block-size='4096' > | xmlns='http://jabber.org/protocol/ibb'> > | urn:xmpp:tmp:tls > | urn:xmpp:tmp:gzip > | > | > | > | | from='[EMAIL PROTECTED]/balcony' > | to='[EMAIL PROTECTED]/orchard' > | id='inband_1'> > | urn:xmpp:tmp:tls > | > > 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/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] New XMPP Use Case: Private Media Networks
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/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] UPDATED: XEP-0234 (Jingle File Transfer)
On 06/04/2008 9:23 PM, Tim Julien wrote: Could you perhaps refrain from top-posting? It makes the conversation hard to follow. :) > The message flow in section 2 (i.e., "happy path") seems good. Only > question I would have is maybe wrap the bytestream / ibb negotiation > messages in jingle transport-info messages. But I can see an argument > against that if the goal is to allow existing implementations to reuse > as much code as possible. Yes, that was the goal. > section 3.1 (Transport Selection) seems good, too. OK, great. > I share your anxiety with Fallback in 3.2 - doing the fallback after > session-accept. Can we modify the PENDING state to allow > content-replace? It seems like we have a real use case for it here. Part of why I wrote the Jingle file transfer spec was to see how the general Jingle state machine would work for more use cases. In the case of fallback, I think the answer is: not very well. We'd have the same issue if we tried to do fallback from XEP-0177 to XEP-0176 (say) for an RTP session. So to me that argues for allowing content-replace during the PENDING state. > I can also envision wanting to do fallback like this for anything that > wants to be non-lossy: > ICE-TCP fallback to -> ICE-RUDP fallback to -> IBB I *think* you're right. I do wonder about fallback in general, that is: when do you know that you need to fall back? In the case you show above, you might try ICE-TCP and it might start to work (you get most of the bits through) but the file is corrupted because you're missing some bits. I think you would have accepted the session by that point, but the transport wasn't as reliable as you would have liked so you basically need to start over. That's a different case than fallback from SOCKS5 to IBB, where you try SOCKS5 but your firewall configuration makes it impossible to use any of the offered streamhosts, so you never get any bits through and need to try IBB. So I think that fallback applies to situations where the transport setup simply fails and you need to try a different transport to get any media flowing at all, rather than the situation where the transport setup worked (send session-accept) but then you have subsequent media problems -- in that situation you'd send a content-replace in the ACTIVE state, whereas in the previous situation you'd send content-replace in the PENDING state. Does that make sense? Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Jingle: content-replace during PENDING state
Peter Saint-Andre wrote: On 06/04/2008 9:00 AM, Paul Witty wrote: Peter Saint-Andre wrote: This is the first in my series of posts on Jingle. More soon. According to version 0.25 of XEP-0166, use of the content-replace action is forbidden during the PENDING state. However, XEP-0176 (ICE-UDP) uses the content-replace action during the PENDING state: http://www.xmpp.org/extensions/xep-0176.html#protocol-acceptance In XEP-0176, this usage maps to nomination of the candidates to be used in ICE, see section 2.6 of draft-ietf-mmusic-ice-19. However, in ICE this nomination is done over STUN, not via SIP/SDP. Therefore I think the content-replace action is unnecessary in XEP-0176 (since nomination in the Jingle ICE-UDP transport will also occur over STUN and does not need to happen in the signalling channel). Unless there are objections, I will update XEP-0176 accordingly (a usage inherited by some of the examples in XEP-0167 and XEP-0180, which will be harmonized with the modified XEP-0176). Peter Can I just get a bit of clarification about how the initiation should work, and what part the user plays in accepting the session. If the session-accept is only sent upon successful completion of ICE, does this mean that the user should only be alerted about the incoming session after ICE is complete, to prevent them accepting a session for which the session-accept will never actually be sent because there are no acceptable candidates? The protocol-level session-accept is different from the user-level button-click involved in making a go/no-go decision about whether the user wants to "pick up the phone" or whatever. I imagine that the client will show the user some kind of interface that requires user interaction to approve the session request after sending the initial ack of the session-initiate and before sending the session-accept. However I suppose that the client should not send the session-accept before the user has had a chance to click the big "accept this call" button. I see two potential call flows here: ICE succeeds, the call works, everyone is happy Romeo Juliet | | | session-initiate | |>| | ack | |<| | session-info (ringing)| |<| | ack | |>| | transport-info (X times) | | (with acks) | |<--->| | STUN connectivity checks | |<--->| | session-accept| |<| | ack | |>| | AUDIO (RTP) | |<===>| | session-terminate | |<| | ack | |>| | | ICE fails, the call fails, Romeo and Juliet poison themselves Romeo Juliet | | | session-initiate | |>| | ack | |<| | session-info (ringing)| |<| | ack | |>| | transport-info (X times) | | (with acks) | |<--->| | STUN connectivity checks | |<--->| | session-terminate | |<| | ack | |>| | | However, in both of these, it makes sense for Juliet to be alerted of the incoming call at the session-info (ringing) stage (that's what ringing means, after all). Juliet being twitchy and waiting for Rome to call, she hits the accept button immediately (i.e. before ICE concludes). In the first example, that's fine. In the second, Romeo has initiated a call, Juliet has hit the answer button, but her client sends a session-terminate message instead. If my telephone rings, I should be sure that the call will succeed when I answer it. As the initiator of the content will be the controlling party for ICE, they will be the one who knows the chosen candidate pair (at least for aggressive nomination; regular nomination makes it unambiguous for both parties as only a single STUN request, which is certain to be received, has the nomination flag). I propose sending a content-modify after ICE completes from the initiator, which declares the nominated candidate pair (with information about the nominated pair being removed from the session-accept), and the called client only alerting the user and sending the session-info (ringing) after receiving this message. This is more in line with the ICE draft, which states: "Once all of the media streams are comp
Re: [Standards] New XMPP Use Case: Private Media Networks
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
Re: [Standards] New XMPP Use Case: Private Media Networks
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 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 . 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 could result in more than one xtls . 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 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. | | | urn:xmpp:tmp:tls | urn:xmpp:tmp:gzip | | | | | urn:xmpp:tmp:tls | 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?
