Re: [Standards] e2e encryption and jingle
Peter Saint-Andre wrote: Ian Paterson wrote: 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? Yes, sorry I meant "are *not* carried out simultaneously". Perhaps a couple of round trips could be saved by *optionally* including the first negotiation elements in the stanzas used for the Encrypted Session negotiation (instead of in subsequent stanzas)? Hmm. This gets back to the old thread about message vs. IQ for Jingle negotiation, forking to multiple resources, etc. Well, we could stipulate that Jingle could only be included with e2e negotiation if the is addressed to a specific resource. 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? I agree that this is not a good idea. However, keeping Jingle and e2e in series only increases latency. We're probably going to have to solve the latency issue at some stage. Does anyone have a good (or at least better) idea how we can do that? AFAICT, nothing currently stops a client conducting both negotiations at the same time in order to minimise latency. So you might even want to discourage that in the Jingle XEP. 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? I agree we need to allow for different methods of e2e, especially at this early stage. Proper layering seems important here. Yes. - Ian
Re: [Standards] e2e encryption and jingle
On 06/09/07, Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > 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. Probably best to keep things as separate as possible, but there should be something binding Jingle to the mechanisms used in e2e encryption. If I have verified another users encryption keys using some out-of-band method, I want that verification to cover any jingle sessions as well. -- Niklas
Re: [Standards] e2e encryption and jingle
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 negotiation elements in the stanzas used > for the Encrypted Session negotiation (instead of in subsequent > 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
Re: [Standards] e2e encryption and jingle
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. 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"). Perhaps a couple of round trips could be saved by *optionally* including the first negotiation elements in the stanzas used for the Encrypted Session negotiation (instead of in subsequent stanzas)? - Ian
[Standards] e2e encryption and jingle
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? -- Niklas
