Ian Paterson wrote: > Niklas Höglund wrote: >> I'd like all my communication to be encrypted end-to-end, so I like >> the development going on in the jabber community on that side. Voice >> calls are also very useful, but from a quick look at the jabber XEPs I >> can't see how these two features should interoperate. >> >> How should this work? >> > > The clients should negotiate an Encrypted Session first. Then the client > should negotiate the Jingle Session. That protects the potentially > sensitive information (e.g. IP addresses) that is exchanged during the > Jingle negotiation. A note about this might usefully be added to the > "5.1 Resource Determination" and/or "Security Considerations" sections > of XEP-0166.
Good idea. > Note that this separation of layers enables the protocols to be used > independently, however, the fact that the two negotiations are carried > out simultaneously creates latency in the establishment of a call > (something that AFAICT is an issue in the "Real World"). Wouldn't they be carried out serially, not in parallel? > Perhaps a couple of round trips could be saved by *optionally* including > the first <jingle/> negotiation elements in the <message/> stanzas used > for the Encrypted Session negotiation (instead of in subsequent <iq/> > stanzas)? Hmm. This gets back to the old thread about message vs. IQ for Jingle negotiation, forking to multiple resources, etc. But in general it doesn't seem like a good idea to mix the protocols in that way. How does the recipient know to look for the Jingle invite in the middle of an encrypted sessions negotiation? Also I don't think we want to tie Jingle and ESessions together. What if we design some other way to do e2e encryption (e.g., "XTLS")? Do we then need to define how that works with Jingle too? Proper layering seems important here. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
