Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)

[Peter Waher]

Hello Peter

I'm travelling at the moment. Let's discuss this XEP in the IoT SIG, along the 
others, in turn.

Best regards,
Peter

Från: Peter Saint-Andre 
Skickat: den 6 januari 2017 17:00:29
Till: XMPP Standards
Kopia: yusuke@toshiba.co.jp; Peter Waher
Ämne: Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) 
Format)

Old thread alert!

On 10/8/14 10:33 AM, XMPP Extensions Editor wrote:
> This message constitutes notice of a Last Call for comments on XEP-0322 
> (Efficient XML Interchange (EXI) Format).
>
> Abstract: This specification describes how EXI compression can be used in 
> XMPP networks.
>
> URL: http://xmpp.org/extensions/xep-0322.html
>
> This Last Call begins today and shall end at the close of business on 
> 2014-10-21.
>
> Please consider the following questions during this Last Call and send your 
> feedback to the standards@xmpp.org discussion list:
>
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
> clarify an existing protocol?
> 2. Does the specification solve the problem stated in the introduction and 
> requirements?
> 3. Do you plan to implement this specification in your code? If not, why not?
> 4. Do you have any security concerns related to this specification?
> 5. Is the specification accurate and clearly written?
>
> Your feedback is appreciated!

I noticed substantive spec and security feedback in October 2014 from
several list participants. However, as far as I can see, that feedback
has not been addressed by the authors.

As part of my review of all the IoT specs, I would like to provide
feedback on XEP-0322, but it seems like wasted effort if the spec hasn't
been updated since the previous last call.

Yusuke & Peter, do you plan to update XEP-0322 or do you need a
co-author to help finish this off?

Peter


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]

[Sam Whited]

On Fri, Jan 6, 2017 at 10:24 AM, Steve Kille  wrote:
> A key problem with this is the JIDs then become anonymous to the channel 
> management.
>
> Having a situation where channel participants do not know who is in a channel 
> is fine.I think that in many situations, it will be beneficial for 
> administration to know real JIDs.   Would you really want to have the XSF 
> Room/Channel full of burner JIDs? Consider if I try to join the 
> channel with a burner JID and nick of "Sam Whited".

If the MIX service is issuing burner JIDs then it could refuse to
issue new burner JIDs to a user if one of that users burner JIDs has
been banned (or simply refuse to allow future burner JIDs issued to
that user into that specific room if they weren't banned from the
whole service), so in a way this could provide "fully anonymous" rooms
where even channel administration does not know the persons real JID
(only the MIX service and its administrators do), but can still ban
that JID.

If the original JID should actually be known by channel administrators
(the semi-anonymous model), the MIX service could publish the users
real JID to a JID mapping node that can only be accessed by channel
admins.

—Sam



-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]

[Sam Whited]

On Fri, Jan 6, 2017 at 10:10 AM, Steve Kille  wrote:
> I don't object to this, but I can't see how it makes much difference to MIX. 
> What impact is there besides following the rules for generating random JIDs?

Using this removes the need for semi-anonymous channels
and proxy JIDs, which will simplify the MIX spec a lot. It shifts the
decision about whether or not a user is
anonymous from the MIX service to the user since they can decide
whether or not to use a burner JID before joining any channels
(although the MIX service would still be able to enforce that a room
be anonymous by only allowing in JIDs issued by its own burner JID
service).

—Sam

-- 
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Burner JIDs and MIX [WAS A possible MIX approach: hiding multiple clients]

[Sam Whited]

On Fri, Jan 6, 2017 at 1:50 AM, Steve Kille  wrote:
> The radical change is to make MIX presence "per user" (at least for JID
> Hidden channels).

I would like to propose an alternative based on XEP-0383: Burner JIDs [1].

If the MIX service itself were to provide burner JIDs a few simple
rules could be enforced by the MIX service to make them work. Burner
JIDs alocated by the MIX service:

  1. MUST have a 1:1 mapping with a real JID
  2. SHOULD NOT expire (although one might envision a situation where
a user starts getting spam to their burner JID so they want to copy
over their roster to a new one to rotate it; this sort of thing could
also be described in the MIX spec if desirable, or maybe the user
really does just want a different proxy JID each time: either way, I
suppose that's a matter of server policy and/or user choice).

This means that users are authenticated using their normal account,
and are authorized to use the MIX service by virtue of having been
assigned a burner JID.

The only real downsides I see to this are that rooms will not show up
in a users normal roster (although this could be solved easily by
clients in the UI, which may even be good because it would mean they
don't show up in clients that don't support MIX), and that it requires
a separate connection to the server for each burner JID in use (if you
wanted a different one per room, that could get expensive). I'm sure
we could solve this by multiplexing multiple sessions over one TCP
connection though, and that's a problem that can be addressed later if
it ever becomes an issue.

Thoughts?

—Sam

[1]: https://xmpp.org/extensions/xep-0383.html

-- 
Sam Whited
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0384: OMEMO Encryption - Feedbacks and proposals

[forenjunkie]

Hi,

I see no downside with your proposal, but the upsides are not as plenty 
as you described.


1. every client gets notified already if a update to the device list is 
made, otherwise OMEMO would not work half of the time


2. there is no code that is added *only* to prevent the race condition, 
a device has always be aware of all device ids that are published, and 
also has to have the ability to delete the whole device list. So in any 
case you need code that sees if your own device id is not in the list 
anymore, and can add itself to the devicelist again. this code is 
additionally also what prevents the race condition. I dont know if its 
easier to just overwrite the list like we do now, or delete all items of 
a node.


It still maybe a cleaner implementation, im not very knowledgeable on 
pupsub/pep.



Am 06.01.2017 um 09:36 schrieb Jaussoin Timothée:
The current usage of PEP is, for me, not optimal and overly complex. 
Having a list of devices that needs to be synchronized on a node and 
their related bundles on some others brings race-conditions issues 
(actually mentioned in the Example 2.) and forces the clients to 
implement extra checks to ensure that everything is properly 
synchronized.


Proposal :

I propose to simply publish the bundles on several items in one unique 
"urx:xmpp:omemo:0" node. Each item ID will be the device ID.


To discover the device ID list a simple 
http://jabber.org/protocol/disco#items query would then be sufficient 
and will rely on existing PEP/Pubsub implementations (client and 
server wise). Furthermore, each client could be instantly notified 
when a device has been added or retracted from the list.


A similar behavior has already been standardized in XEP-0277: 
Microblogging over XMPP.


This seems to already work with servers like Metronome and ejabberd 
(not Prosody for now) and should not cause issues with existing OMEMO 
implementations that are still based on Axolotl and using the 
eu.siacs.conversations.axolotl namespace.


Regards,

Timothée Jaussoin aka edhelas



___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___


___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] A possible MIX approach: hiding multiple clients

[Kevin Smith]

On 6 Jan 2017, at 10:01, Kevin Smith  wrote:
> 
>> 
>> On 6 Jan 2017, at 07:50, Steve Kille  wrote:
>> 
>> 
>> The recent discussion on the difficulty of proxy JIDs has triggered me to
>> write up a more radical idea I have had floating around.
>> 
>> For the most part, a MIX channel deals with users (not clients).   Messages
>> are sent out to each user.  The MIX Proxy (possible new name "MIX
>> Intermediate Server") distributes message and presence to clients.
>> 
>> The place where multiple clients comes through is in presence, where each
>> client shows presence.
>> 
>> The radical change is to make MIX presence "per user" (at least for JID
>> Hidden channels).This seems quite natural to the recipient.   I really
>> don't care how many clients a channel member is running and what their
>> status is.
>> 
>> If we make this change, we can simply get rid of proxy JID.   The user is
>> represented in the channel by the Nick.
>> 
>> There are two downsides to this.
>> 
>> The first is "Nick Stability".   If a user changes their Nick,  a
>> participant in a JID Hidden channel cannot distinguish this from user
>> leaving and a new one joining.   I don't think this is a big deal
>> operationally, but there might be scenarios where this is a problem.
>> 
>> The second relates to the fact that channel members cannot see multiple
>> clients for a user.This has upsides too, but may remove flexibility.
>> 
>> The MIX Intermediate Server will need to set "unified presence".   This is
>> will  sometimes be convenient for channel members, but could be confusing
>> (consider status flapping between two clients).   It feels awkward and messy
>> for the MIX Intermediate Server to work out what to set.
>> 
>> It prevents the channel participant from choosing clients (e.g., by looking
>> at CAPS capability). However for a JID Hidden channel, it seems that in
>> many ways trying to hide the JID and expose multiple clients is a bad thing.
>> 
>> We could work this so that for JID Hidden channels,  the MIX intermediate
>> server MUST provide unified presence.   For JID visible channels, you can
>> simply share full JIDs.
>> 
>> This is quite radical, but I think this idea has legs
> 
> This is the MUC model, which is one of the broken bits of MUC we need to get 
> rid of!

That ‘short’ version was meant to go just to Steve rather than be noise on the 
list, but I’m incompetent. Apologies.

Some more reasons that removing the proxy JID is problematic:

1) As noted, you need to be able to get caps for clients to do various things 
with them. Much of XMPP fails without caps/disco.
2) Nicks are mutable, while you want the proxy JID not to be - both for nick 
change (noted) and re-use/impersonation
3) If we do this for JID-Hidden only, we end up with very different code paths 
for clients for the types of MIXs
4) Merging presence becomes a nuisance (not a problem servers face at the 
moment, while clients already have ways of dealing with merging presence, for 
better or worse).
5) We’re more susceptible (I think) to stale presence issues
6) Probably others

I’ve noted before at summits that I think the multiple-presence thing in XMPP 
is getting to be a nuisance for typical chat systems, but I don’t think MIX is 
the place we want to address this. I think we’d need to address it somewhere in 
core and have the same behaviour for roster and MIX (and wherever else).

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] A possible MIX approach: hiding multiple clients

[Kevin Smith]

> On 6 Jan 2017, at 07:50, Steve Kille  wrote:
> 
> 
> The recent discussion on the difficulty of proxy JIDs has triggered me to
> write up a more radical idea I have had floating around.
> 
> For the most part, a MIX channel deals with users (not clients).   Messages
> are sent out to each user.  The MIX Proxy (possible new name "MIX
> Intermediate Server") distributes message and presence to clients.
> 
> The place where multiple clients comes through is in presence, where each
> client shows presence.
> 
> The radical change is to make MIX presence "per user" (at least for JID
> Hidden channels).This seems quite natural to the recipient.   I really
> don't care how many clients a channel member is running and what their
> status is.
> 
> If we make this change, we can simply get rid of proxy JID.   The user is
> represented in the channel by the Nick.
> 
> There are two downsides to this.
> 
> The first is "Nick Stability".   If a user changes their Nick,  a
> participant in a JID Hidden channel cannot distinguish this from user
> leaving and a new one joining.   I don't think this is a big deal
> operationally, but there might be scenarios where this is a problem.
> 
> The second relates to the fact that channel members cannot see multiple
> clients for a user.This has upsides too, but may remove flexibility.
> 
> The MIX Intermediate Server will need to set "unified presence".   This is
> will  sometimes be convenient for channel members, but could be confusing
> (consider status flapping between two clients).   It feels awkward and messy
> for the MIX Intermediate Server to work out what to set.
> 
> It prevents the channel participant from choosing clients (e.g., by looking
> at CAPS capability). However for a JID Hidden channel, it seems that in
> many ways trying to hide the JID and expose multiple clients is a bad thing.
> 
> We could work this so that for JID Hidden channels,  the MIX intermediate
> server MUST provide unified presence.   For JID visible channels, you can
> simply share full JIDs.
> 
> This is quite radical, but I think this idea has legs

This is the MUC model, which is one of the broken bits of MUC we need to get 
rid of!

/K
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0384: OMEMO Encryption - Feedbacks and proposals

[Jaussoin Timothée]

Hi,

I'm currently in the process of implementing end-to-end encryption in my 
project. I naturally had a look at the freshly published XEP-0384: OMEMO 
Encryption and I have some feedbacks to give on it.


1. Usage of Olm

After some talks with members of the community it seems that this 
protocol was selected for two reasons : it was quite well documented 
(for the crypto part) and didn't have legal concerns.


I was quite disappointed by the library provided by Matrix for this 
protocol (https://matrix.org/git/olm/about/). The Javascript version of 
it needs to be generated from the C/C++ code using a tool called 
emscripten (https://kripken.github.io/emscripten-site/index.html) that 
is actually not packaged on Debian (only a very old version from 2014 is 
available for sid) and seems to rely on a forked version of LLVM.


Also I couldn't find any clear/simple documentation that could help me 
with the integration of the library in a project (like we can have for 
libsignal here 
https://github.com/WhisperSystems/libsignal-protocol-javascript).


2. XMPP environment integration

I also had some concerns regarding the integration and coherence with 
the current XMPP XEPs and syntax.


2.1. OMEMO nodes name syntax

Having node names that use the camelCase syntax is not something that 
I've encountered since the vCard tag in XEP-0054: vcard-temp. I'd prefer 
to stick with the kebab-case (lower-case-dash-separated syntax) like we 
have in the rest of the XEPs. What do you think?


2.2. Current usage of PEP

This feedback is related to the previous message that I sent on this ML 
regarding XEP-0163: Personal Eventing Protocol a couple of days ago (see 
https://mail.jabber.org/pipermail/standards/2017-January/031811.html).


The current usage of PEP is, for me, not optimal and overly complex. 
Having a list of devices that needs to be synchronized on a node and 
their related bundles on some others brings race-conditions issues 
(actually mentioned in the Example 2.) and forces the clients to 
implement extra checks to ensure that everything is properly synchronized.


Proposal :

I propose to simply publish the bundles on several items in one unique 
"urx:xmpp:omemo:0" node. Each item ID will be the device ID.


To discover the device ID list a simple 
http://jabber.org/protocol/disco#items query would then be sufficient 
and will rely on existing PEP/Pubsub implementations (client and server 
wise). Furthermore, each client could be instantly notified when a 
device has been added or retracted from the list.


A similar behavior has already been standardized in XEP-0277: 
Microblogging over XMPP.


This seems to already work with servers like Metronome and ejabberd (not 
Prosody for now) and should not cause issues with existing OMEMO 
implementations that are still based on Axolotl and using the 
eu.siacs.conversations.axolotl namespace.


Regards,

Timothée Jaussoin aka edhelas

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___