[Standards] e2e encryption and jingle

Peter Saint-Andre stpeter at stpeter.im
Wed Sep 5 23:32:39 UTC 2007

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 Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070905/fa6fd8a7/attachment.bin>

More information about the Standards mailing list