[Standards] OpenPGP IM: all stanza types supported?

[Fabian Beutel]

Hey,

tl;dr: OpenPGP-IM should explicitly state that encryption of ALL stanza
types has to bee supported, not just  stanzas.


First, did I interpret the OpenPGP-XEP-0373/374 correctly that any
stanza can be encrypted and not only messages?
If so, I think it might be good to explicitly state that in XEP-0374.

Also, I would suggest to strictly require implementations to
transparently handle the content of the  element.
"[...] SHOULD be processed similar as if they had been direct extension
elements of the stanza" may be a to vague - here I would suggest to use
MUST instead. [1]

That way, when I'm talking to a client that supports XEP-0374 I can be
sure that it understands any encrypted stanza I send and for example
jingle negotiations could happen encrypted.

I created a pull request for these suggestions and would be happy if the
authors would take a look at it! [2]

Best regards,
Fabian


[1] The situation in example 3 in XEP-0374, where the containing stanza
already has a  element ("This message is encrypted using
OpenPGP.") could be handled by requiring that in case of a name
conflict (an element already exists) the encrypted element always takes
precedence over the unencrypted one.

[2] https://github.com/xsf/xeps/pull/249
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Kevin Smith]

On 28 Sep 2016, at 21:18, Tobias M  wrote:
> 
>> 
>> On 28 Sep 2016, at 18:38, Kevin Smith  wrote:
>> 
>> On 27 Sep 2016, at 10:06, Tobias M  wrote:
>>> 
>>> 
 On 27 Sep 2016, at 00:33, Kevin Smith  wrote:
 
> However, it has little discussion on why there is this restriction. While 
> it certainly is a MUST for security reasons in MUC situations where 
> different full JIDs are different accounts (i.e. associated to different 
> bare JIDs), it is less so for security reasons in the non-MUC case.
 
 I think one can construct other situations like MUC, where multiple people 
 control different resources of the same bare JID, but maybe that’s 
 pathological (although I’m not sure).
>>> 
>>> If multiple people would use different resources of the same bare JID, this 
>>> would also lead to strange UX regarding Carbons where the user will see 
>>> messages as sent which they didn’t write. I think this is a rather rare 
>>> edge case we shouldn’t put much efforts in to support.
>> 
>> That may well be true.
>> 
>>> 
 
> I’ve shortly discussed it with other community members in the XSF 
> chatroom [1], but thought I’d bring it up here for discussion with a 
> wider audience, while providing a short summary of the room discussions 
> below:
> 
> When would a client send an correction for a message from another account 
> resource? Two cases come to mind:
> a) Carbons, editing a message from another client when you switch clients 
> mid-discussion.
 
 Certainly in this case we’d want to be able to correct them.
 
> b) Reconnection, where a client has the server assign it a resource.
 
 Which is more or less the same instance as (a), I think.
 
> What do you think? Do you have further comments on this issue?
 
 I think there’s also a concern that different resources may use the same 
 IDs. Perhaps we should be moving away from using stanza IDs for this, and 
 move towards something like 359 (although 359 has the client-id, stanza-id 
 oddity which we should probably fix at some point and just use multiple 
 stanza-id stamps with the relevant ‘by’ instead).
>>> 
>>> Aren’t stanza IDs supposed to be UUIDs, i.e. unique? XEP-0359 could provide 
>>> a solution if we can’t rely on unique and stable stanza IDs. It’s not 
>>> discussed in XEP-0359, but I guess it’s the reason for its existence, that 
>>> stanza IDs may only be stable/unique regarding one XMPP stream and might 
>>> change in a multi-hop routing like C-to-S -> S-to-S -> S-to-C or C-to-S -> 
>>> MUC -> S-to-C.
>> 
>> Sadly not, 6121 says
>> " It is up to the originating entity whether the value of the 'id'
>>   attribute is unique only within its current stream or unique
>>   globally.”
> 
> So, basically XEP-0308 should adopt XEP-0359 in a new version (probably 
> requires namespace version bump) and use the sender's ID for replacements? Is 
> that what you suggest?

It doesn’t seem to be a stupid approach, to me, at least. It has the advantage 
of working in MUCs that do stanza id rewriting, too, as well as working through 
MAM and Carbons, etc.

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

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Tobias M]

> On 28 Sep 2016, at 18:38, Kevin Smith  wrote:
> 
> On 27 Sep 2016, at 10:06, Tobias M  > wrote:
>> 
>> 
>>> On 27 Sep 2016, at 00:33, Kevin Smith >> > wrote:
>>> 
 However, it has little discussion on why there is this restriction. While 
 it certainly is a MUST for security reasons in MUC situations where 
 different full JIDs are different accounts (i.e. associated to different 
 bare JIDs), it is less so for security reasons in the non-MUC case.
>>> 
>>> I think one can construct other situations like MUC, where multiple people 
>>> control different resources of the same bare JID, but maybe that’s 
>>> pathological (although I’m not sure).
>> 
>> If multiple people would use different resources of the same bare JID, this 
>> would also lead to strange UX regarding Carbons where the user will see 
>> messages as sent which they didn’t write. I think this is a rather rare edge 
>> case we shouldn’t put much efforts in to support.
> 
> That may well be true.
> 
>> 
>>> 
 I’ve shortly discussed it with other community members in the XSF chatroom 
 [1], but thought I’d bring it up here for discussion with a wider 
 audience, while providing a short summary of the room discussions below:
 
 When would a client send an correction for a message from another account 
 resource? Two cases come to mind:
 a) Carbons, editing a message from another client when you switch clients 
 mid-discussion.
>>> 
>>> Certainly in this case we’d want to be able to correct them.
>>> 
 b) Reconnection, where a client has the server assign it a resource.
>>> 
>>> Which is more or less the same instance as (a), I think.
>>> 
 What do you think? Do you have further comments on this issue?
>>> 
>>> I think there’s also a concern that different resources may use the same 
>>> IDs. Perhaps we should be moving away from using stanza IDs for this, and 
>>> move towards something like 359 (although 359 has the client-id, stanza-id 
>>> oddity which we should probably fix at some point and just use multiple 
>>> stanza-id stamps with the relevant ‘by’ instead).
>> 
>> Aren’t stanza IDs supposed to be UUIDs, i.e. unique? XEP-0359 could provide 
>> a solution if we can’t rely on unique and stable stanza IDs. It’s not 
>> discussed in XEP-0359, but I guess it’s the reason for its existence, that 
>> stanza IDs may only be stable/unique regarding one XMPP stream and might 
>> change in a multi-hop routing like C-to-S -> S-to-S -> S-to-C or C-to-S -> 
>> MUC -> S-to-C.
> 
> Sadly not, 6121 says
> " It is up to the originating entity whether the value of the 'id'
>   attribute is unique only within its current stream or unique
>   globally.”

So, basically XEP-0308 should adopt XEP-0359 in a new version (probably 
requires namespace version bump) and use the sender's ID for replacements? Is 
that what you suggest?

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

Re: [Standards] XEP-0308: Last Message Correction and Carbons

[Kevin Smith]

On 27 Sep 2016, at 10:06, Tobias M  wrote:
> 
> 
>> On 27 Sep 2016, at 00:33, Kevin Smith  wrote:
>> 
>>> However, it has little discussion on why there is this restriction. While 
>>> it certainly is a MUST for security reasons in MUC situations where 
>>> different full JIDs are different accounts (i.e. associated to different 
>>> bare JIDs), it is less so for security reasons in the non-MUC case.
>> 
>> I think one can construct other situations like MUC, where multiple people 
>> control different resources of the same bare JID, but maybe that’s 
>> pathological (although I’m not sure).
> 
> If multiple people would use different resources of the same bare JID, this 
> would also lead to strange UX regarding Carbons where the user will see 
> messages as sent which they didn’t write. I think this is a rather rare edge 
> case we shouldn’t put much efforts in to support.

That may well be true.

> 
>> 
>>> I’ve shortly discussed it with other community members in the XSF chatroom 
>>> [1], but thought I’d bring it up here for discussion with a wider audience, 
>>> while providing a short summary of the room discussions below:
>>> 
>>> When would a client send an correction for a message from another account 
>>> resource? Two cases come to mind:
>>> a) Carbons, editing a message from another client when you switch clients 
>>> mid-discussion.
>> 
>> Certainly in this case we’d want to be able to correct them.
>> 
>>> b) Reconnection, where a client has the server assign it a resource.
>> 
>> Which is more or less the same instance as (a), I think.
>> 
>>> What do you think? Do you have further comments on this issue?
>> 
>> I think there’s also a concern that different resources may use the same 
>> IDs. Perhaps we should be moving away from using stanza IDs for this, and 
>> move towards something like 359 (although 359 has the client-id, stanza-id 
>> oddity which we should probably fix at some point and just use multiple 
>> stanza-id stamps with the relevant ‘by’ instead).
> 
> Aren’t stanza IDs supposed to be UUIDs, i.e. unique? XEP-0359 could provide a 
> solution if we can’t rely on unique and stable stanza IDs. It’s not discussed 
> in XEP-0359, but I guess it’s the reason for its existence, that stanza IDs 
> may only be stable/unique regarding one XMPP stream and might change in a 
> multi-hop routing like C-to-S -> S-to-S -> S-to-C or C-to-S -> MUC -> S-to-C.

Sadly not, 6121 says
 " It is up to the originating entity whether the value of the 'id'
   attribute is unique only within its current stream or unique
   globally.”

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