Subject: [jose] Some requirements and non-requirements

From: Matt Miller <[email-masked]>
Date: Thu, 17 Nov 2011 17:08:46 +0800

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 - <[email-masked]>
Collaboration Software Group - Cisco Systems, Inc.

---

From: Richard Alimi <[email-masked]>
Date: Sat, 19 Nov 2011 06:18:00 -0800

Hi All,

Thanks Matt for adding the first one.  I'll add information from
ALTO's perspective as well.  Again, some of this was discussed in the
meeting but I'll add it here just for the sake of documenting it and
moving forwards.

What is this "ALTO" thing?

ALTO is a protocol that allows network providers to provide
information about their network and preferences for applications
deciding how traffic transits that network.  It has applications in
the CDN and P2P worlds.

Use Case for JOSE:

The current draft of the ALTO Protocol provides a mode in which
responses from ALTO Server may be redistributed by clients. The
protocol itself does not define a protocol that ALTO Clients use
amongst themselves, but it does document how responses from an ALTO
Server are signed such that ALTO Clients can verify the received
message is intact. Put another way, we use SSL/TLS to provide
integrity on the ALTO Server -> ALTO Client hop, but we use signatures
to provide integrity when sent over ALTO Server -> ALTO Client -> ...
-> ALTO Client paths.

Currently we have a scheme documented in Section 8 of
draft-ietf-alto-protocol-10:
  http://tools.ietf.org/html/draft-ietf-alto-protocol-10#section-8
However, we are nearing completion of the protocol draft and we don't
wish to block publication on JOSE by introducing a normative
dependency. We will be splitting this section into a separate document
so we can move ahead with the remainder of the protocol.

Technically speaking, the current signing mechanism would work today
for us - it is just a bit more wasteful due to the existing
requirement for being URL-safe.  ALTO may have large-ish content
(e.g., a few MB, but up to 100's MB if someone really goes overboard)
that would be signed.  We do care about one-pass encoding and
decoding.  We do not require it to be Base64-encoded or URL-safe.

Requirements:
- One-pass encoding (more important)
- One-pass decoding (slightly-less important, but still important)

Non-Requirements:
- Base64-encoding
- URL-safe

Thanks,
Rich

On Thu, Nov 17, 2011 at 1:08 AM, Matt Miller <[email-masked]> wrote:
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 19 Nov 2011 11:46:52 -0800

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Matt Miller
> Sent: Thursday, November 17, 2011 1:09 AM
> To: [email-masked]
> 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.
>