[Standards] e2e encryption and jingle

[Ian Paterson]

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/>
>> 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 <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.
>   

Yes.

- Ian