[Standards] e2e encryption and jingle
ian.paterson at clientside.co.uk
Thu Sep 6 14:32:01 UTC 2007
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 <jingle/> negotiation elements in the <message/> stanzas used
>> for the Encrypted Session negotiation (instead of in subsequent <iq/>
> 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 <message/> 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.
More information about the Standards