Re: [jose] Some requirements and non-requirements

[Matt Miller <[e-mail]>]

On Nov 19, 2011, at 12:46, Jim Schaad wrote:

> Which of the encryption algorithms do you already have specified in XMPP and
> thus would probably prefer.  Do you use the GCM modes and if so do you use
> them in AEAD (authenticated encryption with associated data) or just as AE?
> 
> Jim
> 

To date, we don't have any specific algorithms defined.  The draft <draft-miller-3923bis> has an MTI of AES_CBC_128 with an application-level MAC (HMAC_SHA_256).

I'm personally hesitant to require GCM because it does not appear to be widely deployed yet.


- m&m

Matt Miller - <[e-mail]>
Collaboration Software Group - Cisco Systems, Inc.

> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> Matt Miller
>> Sent: Thursday, November 17, 2011 1:09 AM
>> To: [e-mail]
>> Subject: [jose] Some requirements and non-requirements
>> 
>> A number of us had a short discussion in the hall in Taipei not-too-long
> ago,
>> and came up with some needs (and non-needs) that differ from the current
>> proposals.  Some of this was stated in the meeting, some may not have
>> been.  My explanation and requirements/non-requirements follow; I'll let
>> the others send their own comments.
>> 
>> We (XMPP) have an asynchronous protocol that involves multiple hops (most
>> often no more than 3), and have a need to protect this information end-to-
>> end.  However, the end-points are not guaranteed to be singular; the
>> protocol allows for a single account or bare JID to have multiple
> simultaneous
>> resources involved.  It is possible that the sender will not know
> precisely
>> which resource will ultimately receive a stanza, but it is possible that
> such a
>> sender will know of all the possible recipients, and have asymmetric keys
> for
>> each of these recipient end-points.  Since one of our stanza kinds is
> intended
>> for conversations, it would be desired (but not absolutely necessary) to
> be
>> able to reuse a session key across multiple discreet payloads.
>> 
>> Further, authenticity or integrity of the data is not always important.
> For
>> various reasons, there is assurance in the asserted identity of each
> entity.
>> That's not to say it's *never* important, but that there exists other
> factors
>> that make it less important in a lot (I would say most) cases.
>> 
>> With all of that, we have the following requirements:
>> 
>> * Support multiple known recipients
>> * data needs to be standalone XML safe
>> 
>> And the following non-requirements:
>> 
>> * data need not always be signed
>> * data need not be URL safe
>> * data need not be tightly coupled/interleaved with the meta-data
>> 
>> 
>> - m&m
>> 
>> Matt Miller - <[e-mail]>
>> Collaboration Software Group - Cisco Systems, Inc.
>> 
>> 
> 
>