Subject: [xmpp] E2E Slides

From: Matt Miller <[email-masked]>
Date: Thu, 21 Jul 2011 17:32:43 -0600

Attached is the current version of my current slides.

- m&m

Matt Miller - <[email-masked]>
Collaboration Software Group - Cisco Systems, Inc.

---

From: Justin Karneges <[email-masked]>
Date: Thu, 21 Jul 2011 16:47:54 -0700

I like this, especially the part about packaging the signed stanza into the 
e2e blob.  This avoids canonicalization problems.

Btw, the approach is almost the same as what I documented long ago:
  http://xmpp.org/extensions/inbox/secure.html

If I had the energy I would still try to push this XEP (JEP?), since it seems 
the e2e discussion has come all the way back around to single stanza security 
again.  Oh well, maybe some useful ideas from it can be taken instead.

---

From: Waqas Hussain <[email-masked]>
Date: Fri, 22 Jul 2011 05:48:05 +0500

> Collaboration Software Group - Cisco Systems, Inc.

I'm not sure if this is the appropriate time or place to question
this, but I'll just go ahead.

Question: What threat does this form of E2E attempt to protect the end
users from?

Given the dependence on PEP, any MITM (including the servers of the
users) can render this useless. So if this isn't attempting to protect
against the servers or any other MITM with the ability to modify the
stream, what exactly is this protecting against? What am I missing
here?

And what does PEP gain us here? Wouldn't querying the contact's
resource for the public key work better, since it could possibly
generate a key (possibly based on out-of-band communication)? This
would also mean separate clients could have separate keys, thus the
compromise of one client machine would not cause a leak of a critical
private key of the user, just that one client's.

--
Waqas Hussain

---

From: Ben Campbell <[email-masked]>
Date: Thu, 21 Jul 2011 22:23:13 -0500

> this, but I'll just go ahead.

[actual discussion ellided]

I'd argue that this is the _best_ place to question things, as it's the list of record for the working group :-) The more we have out in the open on the list, the faster the f2f meeting will go.

Thanks!

Ben.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 21 Jul 2011 21:30:23 -0600

> I'd argue that this is the _best_ place to question things, as it's the list of record for the working group :-) The more we have out in the open on the list, the faster the f2f meeting will go.

+1

---

From: Matt Miller <[email-masked]>
Date: Fri, 22 Jul 2011 07:46:26 -0600

Thank you for taking the time to look at the slides.

Further comments inline...

> e2e blob.  This avoids canonicalization problems.

Canonicalization is one issue most of the other object-based proposals haven't really addressed.  I think this sidesteps the issue altogether, which might help adoption.

>  http://xmpp.org/extensions/inbox/secure.html

I had forgotten about that one! After a quick read, it looks like I'm following a fairly similar pattern, but using the octet-string representation of the stanza as the input data for encrypting/signing.

> again.  Oh well, maybe some useful ideas from it can be taken instead.

As stpeter would say, "the more the merrier!" (-:

- m&m

---

From: Matt Miller <[email-masked]>
Date: Fri, 22 Jul 2011 08:04:08 -0600

> private key of the user, just that one client's.

Using PEP has a number of advantages:

* The public keys can be obtained whether the user is online or offline.
* Updating keys automatically notifies the interested parties.

It does mean that you need to trust PEP data.  It might (should?) be possible to take other steps to verify the public keys.

- m&m

---

From: Kevin Smith <[email-masked]>
Date: Fri, 22 Jul 2011 15:26:07 +0100

> It does mean that you need to trust PEP data.  It might (should?) be possible to take other steps to verify the public keys.

Using PEP seems to make a lot of sense to me - I'm assuming that
whatever the mechanism for retrieving keys they're still going to need
to be verified in some manner.

/K