Re: [Standards] XEP-0016, blocking incoming IQs - interpretation problem

[Bartłomiej Górny]

On 08/05/2020 14:34, Florian Schmaus wrote:

On 5/8/20 12:41 PM, Bartłomiej Górny wrote:

Hello

We have a question, how exactly should a privacy list behave if it is
set up to block all incoming IQs. Namely: should it block all incoming
iqs whatsoever (including iq responses to the user's iq requests sent to
the server, iq pushes from the server etc), or only iq stanzas sent by
other users (entities with non-empty localpart other then the user's own)?


 From xep16:

 -- blocks incoming IQ stanzas

so this means all IQ stanzas, independently of their type.



Thanks for answering. We are not wondering about types of iqs, though, 
but about senders. If we block iqs from an entity it is quite clear that 
it should block get, set etc. The question is basically, how to 
interpret example 44. Should a global block on iqs block stanzas from 
other users only, or from all entities - users, servers, my server, my 
server account?


BG




Whether or not if this is sensible is another question

Clients wishing to perform an IQ request could switch to a temporary
privacy list (or modifying the active list) prior sending the IQ request
which allows IQs from the remote entity for the time of the request.

- Florian



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



--


Code Sync & Erlang Solutions Conferences 



*
*

Code BEAM 
Lite ITA - Bologna: Rescheduled


Code BEAM STO - Stockholm: Rescheduled


ElixirConf EU - Warsaw: 7-8 October 2020

Code Mesh - London: 5-6 November 
2020


*
*

Erlang Solutions cares about your data and privacy; please find 
all details about the basis for communicating with you and the way we 
process your data in our Privacy Policy 
. You can update your 
email preferences or opt-out from receiving Marketing emails here 
.


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

[Standards] XEP-0016, blocking incoming IQs - interpretation problem

[Bartłomiej Górny]

Hello

We have a question, how exactly should a privacy list behave if it is 
set up to block all incoming IQs. Namely: should it block all incoming 
iqs whatsoever (including iq responses to the user's iq requests sent to 
the server, iq pushes from the server etc), or only iq stanzas sent by 
other users (entities with non-empty localpart other then the user's own)?


Thanks in advance
Bartek Górny

--


Code Sync & Erlang Solutions Conferences 



*
*

Code BEAM 
Lite ITA - Bologna: Rescheduled


Code BEAM STO - Stockholm: Rescheduled


ElixirConf EU - Warsaw: 7-8 October 2020

Code Mesh - London: 5-6 November 
2020


*
*

Erlang Solutions cares about your data and privacy; please find 
all details about the basis for communicating with you and the way we 
process your data in our Privacy Policy 
. You can update your 
email preferences or opt-out from receiving Marketing emails here 
.


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

Re: [Standards] XEP-0016, blocking incoming IQs - interpretation problem

[Florian Schmaus]

On 5/8/20 2:55 PM, Bartłomiej Górny wrote:
> On 08/05/2020 14:34, Florian Schmaus wrote:
>> On 5/8/20 12:41 PM, Bartłomiej Górny wrote:
>>> Hello
>>>
>>> We have a question, how exactly should a privacy list behave if it is
>>> set up to block all incoming IQs. Namely: should it block all incoming
>>> iqs whatsoever (including iq responses to the user's iq requests sent to
>>> the server, iq pushes from the server etc), or only iq stanzas sent by
>>> other users (entities with non-empty localpart other then the user's
>>> own)?
>>
>>  From xep16:
>>
>>  -- blocks incoming IQ stanzas
>>
>> so this means all IQ stanzas, independently of their type.
> 
> 
> Thanks for answering. We are not wondering about types of iqs, though,
> but about senders. If we block iqs from an entity it is quite clear that
> it should block get, set etc. The question is basically, how to
> interpret example 44. Should a global block on iqs block stanzas from
> other users only, or from all entities - users, servers, my server, my
> server account?

Ahh, yes, the dreaded example 44.

Strictly following the XEP would mean that you will not even get IQ
responses from any subsequent privacy-list related IQ request. Or any
other IQ from the service.

I personally think that servers implementing xep16 should *always* allow
stanzas from themself (not sure if this includes internal components
though, I think not). That is why I have created

https://issues.igniterealtime.org/browse/OF-724

6 years ago.

I'd love to get that clarification into xep16 too. But someone™ needs to
do it.

- Flroain




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

Re: [Standards] XEP-0016, blocking incoming IQs - interpretation problem

[Florian Schmaus]

On 5/8/20 12:41 PM, Bartłomiej Górny wrote:
> Hello
> 
> We have a question, how exactly should a privacy list behave if it is
> set up to block all incoming IQs. Namely: should it block all incoming
> iqs whatsoever (including iq responses to the user's iq requests sent to
> the server, iq pushes from the server etc), or only iq stanzas sent by
> other users (entities with non-empty localpart other then the user's own)?

From xep16:

 -- blocks incoming IQ stanzas

so this means all IQ stanzas, independently of their type.

Whether or not if this is sensible is another question.

Clients wishing to perform an IQ request could switch to a temporary
privacy list (or modifying the active list) prior sending the IQ request
which allows IQs from the remote entity for the time of the request.

- Florian




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

Re: [Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

[Florian Schmaus]

On 5/8/20 12:10 AM, Sam Whited wrote:
> On Thu, May 7, 2020, at 15:49, Florian Schmaus wrote:
>> I am sure we do not need an version bump for this. The information of
>>  falls into the category "additional
>> information that is nice to have but not (strictly) required". We
>> extend existing elements by new elements or attributes without a
>> namespace bump all the time.
>>
>> https://tools.ietf.org/html/draft-cridland-xmpp-session-01 is a nice
>> example of this.
> 
> I read that through a few times, but I don't really understand how it
> applies to the current discussion.

It adds a previously unspecified  to , which is
exactly what  is to . That
 is not under a different namespace largely irrelevant.
Suddenly there is a now element unknown to implementations unaware of it.


> It does not appear to arbitrarily
> modify another extensions namespace, it just creates a new (well, an
> "old" but it's new again in 6120) stream feature,a defined point of
> extensibility that is very common. Can you please elaborate, or, better
> yet, find an existing widely implemented XEP that adds payloads to
> another XEP or RFCs namespace?

It does not matter if it is an widely implemented XEP or not. The fact
alone, that we extend elements by further elements/attributes later on
without a namespace bump, means that your validation mechanism should
not choke on unknown elements/attributes.

But sure, I will do some digging for you, here you go:

https://github.com/xsf/xeps/commit/1b89aa4e0011512cca6635b302e95296ce8aed02


>> Are you sure you did not misunderstand that?
> 
> Yup, like I said in my previous email it's quite possible that I'm
> misremembering and someone who actually works on a product that does
> this will need to chime in.
> 
> 
>> Why would this be desirable from a security perspective? In the end,
>> your implementation will simply ignore unknown elements/attributes.
>> There is no gain in security if you error out before.
> 
> In general it's best practice to not allow arbitrary input in security
> critical contexts (like auth).
We do not allow input, we ignore it.


> Our client MAY just ignore it, or we may
> be using that message later, eg. hashing it into some other data so that
> the hash will become invalid if the auth mechanisms change, and we don't
> want arbitrary other text in there breaking our hash.

That argument is flawed. If we ever where to hash , then we
would do what we always do when it comes to hashing: clearly specify
which data is hashed and in which order. As otherwise, you would need to
resort to XML normalization, which you usually do not want to do, due
its complexity. And explicitly specifying what gets normalized comes
with the advantage that you can later extend the elements by additional
elements/attributes, without breaking the hashing scheme. An example of
this is the hashing algorithm specified by xep115/390.


> To be clear, I
> don't know of anything doing this in the wild, and I'm not suggesting
> that adding things will definitely be a security vulnerability (in fact,
> it almost certainly won't be) but we'd want to be very careful before
> adding more stuff to . All that being said, that really wasn't the
> point of the paragraph you were replying to and it's not a hill I'd want
> to die on. I just mention it as one reason being stricter about the
> namespaces during this step might be something people are doing.

And again, if you you do a strict schema validation that errors out as
soon as it finds an unknown element or attribute (prefixed or not), then
you have not understand how extending XMPP works.

Schema validation in XMPP is about validating *known* elements and
enforce the rules. Like, if there is a {foo}bar element, then it must
have a boolean attribute named 'required'. Or, if there is a {foo}baz
element, then it must have a at least three {foo}option child elements.

If entities where to enforce such a strict schema validation as you
argue with, then we would take away an easy way to upgrade the protocol
without (namespace) version bumps for no gain.


>> That [backwards compatibility] is what my proposal allows.
> 
> Didn't you just say it was possible that your proposal would break
> existing clients or servers that don't support the new extension? Maybe
> I misunderstood, but I don't see how that's compatible with "Even though
> it means an enforcing server would *potentially* block clients unaware
> of this extension."?

No, I said,
"Even though it means an enforcing server would
*potentially* block clients unaware of this extension."

The "potentially block" may be a little bit confusing, so let us play a
game (CB is channel binding in the following):

Non-CB enforcing server + No 
→ Same situation as when  did not exist, clients
  may select an unsupported CB and chaos ensues. What then? Can you
  (re)try SASL directly again? Will the client disconnect and try again?

Non-CB enforcing server + 
→ The client knows which CBs are supported, *no* ch