CPIM insufficient for end-to-end security?

--=-=-=


Hi.  I was asked to review the XMPP working group's end-to-end
encryption draft.  The hope was that this draft would use CPIM to
provide a mechanism for end-to-end encryption within XMPP and for
other systems that supported CPIM.

During this review, I believe I found two deficiencies in CPIM that
render it inadequate for this task.  I believe it is possible to fix
these problems.

While I realize that the IMPP documents have already been sent to the
IESG, it is probably worth trying to convince the IESG to fix a
problem that prevents the documents from meeting their fundamental
goal.

The two problems I found were as follows:

1) CPIM seems not to specify how an IM client verifies that a
certificate is valid for a particular presentity or instant inbox.

2) The CPIM documents don't specify mandatory-to-implement algorithms.


It's also possible that both I and the XMPP draft author missed the
specification of these two issues.  If so, please feel free to point
out the appropriate text.

--Sam






--=-=-=
Content-Type: message/rfc822
Content-Disposition: inline

Return-Path: <[email protected]>
Received: from solipsist-nation ([unix socket])
	by solipsist-nation (Cyrus v2.1.5-Debian2.1.5-1) with LMTP; Mon, 28 Jul
 2003 20:23:12 -0400
X-Sieve: CMU Sieve 2.2
Return-Path: <[email protected]>
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU
 [18.7.7.76])
	by suchdamage.org (Postfix) with ESMTP id 9C1A3131D8
	for <[email protected]>; Mon, 28 Jul 2003 20:23:11 -0400 (EDT)
Received: from hades.jabber.org
 (hades.all-your-IM-are-belong-to-us.jabber.org [208.245.212.109] (may be
 forged))
	by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h6T0NBhT018086
	for <[email protected]>; Mon, 28 Jul 2003 20:23:11 -0400 (EDT)
Received: from hades (hades [127.0.0.1])
	by hades.jabber.org (Postfix) with ESMTP
	id 8282B63F32; Mon, 28 Jul 2003 19:23:02 -0500 (CDT)
Delivered-To: [email protected]
Received: from lor.jeremie.com (lor.jeremie.com [208.245.212.28])
	by hades.jabber.org (Postfix) with ESMTP id 2F62763F2F
	for <[email protected]>; Mon, 28 Jul 2003 19:22:18 -0500 (CDT)
Received: from konishi-polis.mit.edu (STRATTON-TWO-SIXTY-TWO.MIT.EDU
 [18.187.6.7])
	by lor.jeremie.com (8.9.3/8.9.3) with ESMTP id TAA26042
	for <[email protected]>; Mon, 28 Jul 2003 19:22:17 -0500
Received: by konishi-polis.mit.edu (Postfix, from userid 8042)
	id 6FD621515C4; Mon, 28 Jul 2003 20:22:17 -0400 (EDT)
To: [email protected]
Message-Id: <[email protected]>
From: [email protected] (Sam Hartman)
Subject: [xmppwg] Review of E2E draft draft-ietf-xmpp-e2e-04
Sender: [email protected]
Errors-To: [email protected]
X-BeenThere: [email protected]
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Unsubscribe: <http://jabber.org/cgi-bin/mailman/listinfo/xmppwg>,
	<mailto:[email protected]?subject=unsubscribe>
List-Id: Mailing list of the IETF's XMPP Working Group <xmppwg.jabber.org>
List-Post: <mailto:[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <http://jabber.org/cgi-bin/mailman/listinfo/xmppwg>,
	<mailto:[email protected]?subject=subscribe>
List-Archive: <http://jabber.org/pipermail/xmppwg/>
Date: Mon, 28 Jul 2003 20:22:17 -0400 (EDT)
X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20
X-Spam-Level: *
MIME-Version: 1.0


Hi.  At the Vienna IETF, I agreed to read over the e2e draft and give
my comments.

The overall document quality is good; I believe it needs an id-nits
pass before last call, but the examples and text were clear to me as a
reader.

I do have two concerns with the draft.  



Section 6.3 describes how jids should be encoded in certificates.
However, as I recall we're not defining an xmpp-specific
infrastructure e for e2e encryption/signing.  We're defining how to
use XMPP for CPIM e2e.  To get interoperability with CPIM, we need to
define the naming at the CPIM level, not at the XMPP level.  So, while
we may wish to specify a way of binding a jid to a certificate for use
in a pure XMPP environment, we need to make sure there is sufficient
behavior specified in the CPIM case for interoperability.  Ideally,
the CPIM documents define how to map instant inbox names to
certificates.  Then all we need to do is define how to map jids to
instant inbox names.


If the CPIM documents do not define a mapping from instant inbox names
to certificates, then the CPIM documents are insufficiently detailed
for interoperable implementation.  It is my opinion that unless this
deficiency is fixed, the CPIM documents do not provide sufficient
facilities for end-to-end security.


I have a similar problem with section 6.7.  To guarantee
interoperability, CPIM need to specify what algorithms must be
implemented.  If CPIM does not do this then we cannot guarantee
interoperability with non-XMPP environments.



Finally, I have a question about S/MIME usage.  Is it traditional in
S/MIME to sign encrypted data rather than say encrypting signed data,
or perhaps encrypting and signing in a single operation?  I don't know
enough about S/MIME to answer this myself.


--Sam
_______________________________________________
xmppwg mailing list
[email protected]
http://jabber.org/cgi-bin/mailman/listinfo/xmppwg


--=-=-=--



  [reminder: [email protected] for non-technical discussions, please]