Subject: [xmpp] Fwd: I-D Action:draft-miller-3923bis-00.txt

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Mar 2010 17:18:29 -0700

FYI. This document sketches out an alternate approach to meeting our
end-to-end encryption requirements, if only to initiate more discussion
about the topic...

/psa

-------- Original Message --------
Subject: I-D Action:draft-miller-3923bis-00.txt
Date: Mon,  1 Mar 2010 16:15:01 -0800 (PST)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : End-to-End Object Encryption for the Extensible
Messaging and Presence Protocol (XMPP)
	Author(s)       : M. Miller, P. Saint-Andre
	Filename        : draft-miller-3923bis-00.txt
	Pages           : 10
	Date            : 2010-03-01

This document defines a method of end-to-end object encryption for
the Extensible Messaging and Presence Protocol (XMPP).  The protocol
defined herein is a simplified version of the protocol defined in RFC
3923.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-miller-3923bis-00.txt

---

From: Sean Turner <[email-masked]>
Date: Mon, 01 Mar 2010 21:43:38 -0500

Peter,

I just skimmed this quickly and what jumped out at me was that this 
mechanism should build algorithm agility in from the start (i.e., 
include an indication of the algorithms used to secure the stanza). 
There's no shortage of protocols that hard coded one algorithm and then 
enjoyed the time consuming effort of adding algorithm agility to a 
version 2 of the protocol.

spt

Peter Saint-Andre wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Mar 2010 19:46:02 -0700

Agreed. We were rushing to meet the -00 deadline and plan to specify
algorithm agility in -01.

---

From: Kurt Zeilenga <[email-masked]>
Date: Mon, 1 Mar 2010 19:26:25 -0800

Peter, Matthew:

Why are there copies of the time stamp and thread id sent in the clear?

I would think that having in-the-clear copies would raise some security concerns.

Is there any particular reason why the time stamp inside the object to be signed is simply pre-append to the stanza instead of including it in an element of stanza?

Regards, Kurt

---

From: Matthew Miller <[email-masked]>
Date: Tue, 2 Mar 2010 07:57:53 -0700

> I would think that having in-the-clear copies would raise some security concerns.

What's not normatively stated is that the visible <thread/> is (SHOULD, MUST?) be different than the encrypted version.  Clients use <thread/>s to note the conversation flow. That said, and now that I've stepped back from it for a while, I see the concern.

We didn't see the timestamp as something to be concerned with, however.

> Is there any particular reason why the time stamp inside the object to be signed is simply pre-append to the stanza instead of including it in an element of stanza?

This is how a work-in-progress implementation is doing it, and it so far is proving easy to deal with.  Attempting to embed the timestmap into the stanza will not work with <iq/>-style stanzas, and is the main reason we avoided that.

---

From: Kurt Zeilenga <[email-masked]>
Date: Tue, 2 Mar 2010 12:26:05 -0800

> What's not normatively stated is that the visible <thread/> is (SHOULD, MUST?) be different than the encrypted version.  Clients use <thread/>s to note the conversation flow. That said, and now tha…

I would assume that the receiving client should rely only on the signed and encrypted data and hence would assume that all other information is for the benefit of other entities.  If the outside thread-id serves no other entity, it might be extraneous.

> We didn't see the timestamp as something to be concerned with, however.

I had two concerns.  One simply carrying useless copies.  That is, the receiving client would rely only on the inside timestamp.  As above, the outside timestamp might be extraneous.

But I wonder if having a copy of the timestamp on the outside might aide in mounting some sort of known/chosen plain text attack.  I'll leave that to the crypto experts to analyze.

-- Kurt