[Standards] Re: NEW: XEP-0474 (SASL SCRAM Downgrade Protection)

[Ruslan N. Marchenko]

Am Samstag, dem 28.10.2023 um 14:40 +0100 schrieb Matthew Wild:
> 
> So, SSDP "only" allows the client to detect the difference between
> two cases:
> 
> 1) The real server advertises new channel binding methods the client
> does not understand
> 2) An MITM is trying to trick the client into authenticating
> 
> In both cases the client must abort the authentication. What's
> gained?
> 
No

> Or are you saying that in case 1 the client should feel free to try a
> SASL mechanism that does not do channel binding?

Hi Matthew,

Client is always free to use whatever method and mechanism it wants. 
SSDP just allows extending SASL SCRAM tampering protection to
application layer. Meaning the client made mech/tls-binding selection
while being fully aware of all available alternatives and nothing
outside of the existing security context influenced that decision.

And tampering protection is common for SASL SCRAM, tampered
communication should result in failed authentication and hence no
access to protected data (eg unencrypted communication). Regardless
what exactly is being tampered with (ClientProof/ServerSignature
mismatch).

Regards,
Ruslan


signature.asc
Description: This is a digitally signed message part
___
Standards mailing list -- standards@xmpp.org
Info: Unsubscribe: %(real_name)s-unsubscribe@%(host_name)s
___

Re: [Standards] Fwd: [Uta] STARTTLS vulnerabilities

[Ruslan N. Marchenko]

Am Mittwoch, dem 11.08.2021 um 14:25 -0600 schrieb Peter Saint-Andre:
> Too bad we didn't stick to our guns in 2003 and insist on two ports
> instead of one, but STARTTLS was the recommended approach back
> then...
> 
I am still not convinced the STARTTLS is ultimate evil. SMTP had way
too many bugs in its implementation over its history, still no one
considers it evil. And that's just yet another of those bugs. And
considering network transparency becomes bigger rarity nowadays - port
multiplication is a must. And we are yet to see how many of similar
bugs will be in alpn/sni implementations.

--rr

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

Re: [Standards] Council Minutes 2021-02-03

[Ruslan N. Marchenko]

Am Mittwoch, dem 10.02.2021 um 19:37 +0100 schrieb Thilo Molitor:
> > I cannot recall now where exactly it was but there was definitelly
> > something about the order of the fields somewhere, because I
> > remember
> > adding a separate list with original key order to be able to use
> > hashmap while still preserving the order. But I really cannor
> > recall
> > where it was coming from :(
> Maybe this one:
> https://xmpp.org/extensions/xep-0115.html#ver-gen entry 7b and 
> 7cb
> 
That goes about explicit sorting which removes necessity to preserve
order. But 0115 was the reason I implemented forms in the first place
and I've added ordering support later. So should be something
different. Maybe it was just for unit tests though (to have predictable
order).

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

Re: [Standards] Council Minutes 2021-02-03

[Ruslan N. Marchenko]

Am Mittwoch, dem 10.02.2021 um 17:28 +0100 schrieb Jonas Schäfer:
> Thanks for the minutes!
> 
> 
> As of now, I’m still -1.
> 
> I want to elaborate the reason a little. Note that my -1 is solely
> based on 
> the ordering requirement for , not the other commit in
> that PR.
> 
> I am not aware of any place where we impose an ordering between
> elements which 
> have *different* fully-qualified XML names (i.e. after namespace
> expansion) [in 
> any Draft or significantly deployed standard]. Introducing this
> requirement 
> means that implementations cannot use hash maps which map the element
> type 
> (fully-qualified XML name) to a list of element representing objects
> anymore, 
> because that structure does not allow storing the ordering of
> unrelated 
> elements. If you have concrete examples where that is the case,
> please let me 
> know.
> 

I cannot recall now where exactly it was but there was definitelly
something about the order of the fields somewhere, because I remember
adding a separate list with original key order to be able to use
hashmap while still preserving the order. But I really cannor recall
where it was coming from :(

> Introducing this restriction this late into the standards process for
> no 
> interoperability reason and in a Final standard is not justified.
> 
> kind regards,
> Jonas
> ___
> 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] Proposed XMPP Extension: Stickers (use of PubSub)

[Ruslan N. Marchenko]

Am Donnerstag, den 19.11.2020, 18:10 +0500 schrieb Andrew Nenakhov:
> So of course, we use HTTP
> for hosting sticker packs and stickers themselves, and any client on
> any OS can *easily* import any image by their URIs. This way clients
> do not need to use pubsub or anything, just use the links, super
> easy.
> Also, this model makes updating the pack more easy.
> 
> Beyond that, we've actually come to understanding that single-connect
> model is fundamentally broken and stands in the way of good, and have
> rather successfully implemented multiple streams into clients. So
> loading dreaded presences and new messages come in the main stream,
> where you post presence, and loading an archive for specific
> conversations happens in another. Fetching list of group chat members
> happens in another, etc. On iOS (and on Android too, actually) it is
> almost always faster to open a new stream and fetch only the required
> data, than to load everything on the only stream. This makes
> interfaces far more responsive, and, among other things, makes stream
> management unnecessary.
> 
I think you are just reinventing matrix protocol. If xmpp is so non-
usable on apple devices why bother making non-interoperable protocol
(or client) when there's is already what you'll likely end up with.
Just make a protocol gate to xmpp if you still want to support that.

--rr


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

Re: [Standards] Use of XEP-0198 resumption under adverse network conditions

[Ruslan N. Marchenko]

Am Mittwoch, den 04.11.2020, 11:46 + schrieb Dave Cridland:
> 
> Due to network analysis (and "thanks" to a bug in the server which
> caused some useful logging), we were able to examine not only when
> sessions went into the unresponsive state, but also when the client
> subsequently sent traffic on that session. This often happened well
> after the session had fallen into the resumable state - this resulted
> in an error, as the session had been closed.
> 
> Having seen the result of this in the logging of the server, we
> followed up by looking for the same logging output on the production
> system, where the majority of users are using WiFi or 4G within
> hospitals. Coverage is often poor, and the WiFi overused, so
> clinicians often operate on a weak 4G signal, or highly contented
> WiFi. Think FOSDEM.
> 
> Again, we observed clients recovering sometimes well after the ping
> timeout had triggered. Had these clients been able to, they could
> have continued to use the same TCP session without any disruption
> (or, for that matter, any additional RTTs re-establishing).
> 
> The usual approach here seems to be to increase the timeout required
> to move a session from "live" to "unresponsive" when pinged. However,
> this has the effect of delaying push notifications while the session
> is, in effect in limbo.
> 
> Our proposal is that when a session is found to be unresponsive, the
> server starts sending push notifications for unacknowledged (and
> future) messages, but otherwise leaves the session live when
> resumable. Only after a significantly longer timeout should the TCP
> session be terminated (and at that point destroy the session
> entirely).
> 

Matches my observations [1] as well. If the session is not too active
tcp recovery is instant, all the snd/rcv buffers are flushed and then
queues are flushed and all live as if nothing happened. 

> This means that a client recovering network after several minutes
> will find the connection still live (in effect), whereas if it never
> recovers, it will still get the push notifications in a timely
> manner.
> 
> There are likely to be downsides with this approach; particularly
> presence state will be badly affected. PSA could help here. Overall,
> though, we believe that this will substantially improve the effective
> performance of C2S over high latency, high contention links.

I'm leaning towards ignoring all the timers whatsoever, only care about
how it affects UX. If tcp is still holding up - let it be, if it got
EOF/EOS/Timeout (from whatever side) - let's just do resumption
reconnection - we're reconnectiong continuously anyway.

1. -
 https://github.com/TelepathyIM/wocky/issues/14#issuecomment-720091807
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Fixing XEP-0066 (Out of Band Data)

[Ruslan N. Marchenko]

Am Freitag, den 23.10.2020, 15:04 + schrieb Tedd Sterr:
> (This is tangential to Dave's thread, but I didn't want to hijack
> that, hence a new one.)
> 
> There may be some argument to include the url in the body anyway for
> backwards compatibility, but given the XEP is over 14 years old and
> has a disco feature, is that really appropriate? If something can
> easily be made backwards-compatible then why not, but should we avoid
> doing anything advanced because it won't work properly in Pigeon?
> There is also the usual MUC issue, but things intended for one-to-one
> obviously aren't guaranteed to work there, and breaking everything
> just so they will work with MUC is going backwards.
> 
I think the url in the body is a nice way to make a placeholder for
inline image (if url element matches exactly url in the body it is
replaced/extended with actual image). 
I for one was adding URL to the body as a marker for oob data in
libpurle (as it does not otherwise allow linking protocol and ui legs).
Limiting body only to the url - that part i never understood and
couldn't fish it out from any standard - although if we now allow body
to be arbitrary - that particular libpurple plugin will be broken.
Which is not a big deal tbh, just a new challenge.

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

Re: [Standards] Call for Experience: XEP-0363: HTTP File Upload

[Ruslan N. Marchenko]

Am Mittwoch, den 21.10.2020, 16:28 +0100 schrieb Dave Cridland:
> 
> This specification is primarily intended for, and used for, the
> purpose of transferring a file from one user to another.
> 
> In practise, the clients upload a file, thereby obtaining a URL, and
> pass that URL somehow to the other party.
> 
> My question - and it is a question -  is whether we ought to be
> advancing this specification when its usage is contingent on the
> proper definition of that "somehow".
> 
> I can see arguments both ways - this can be used independently, after
> all, but it's primary use is as part of the "complete breakfast" of
> file transfer. Advancing something to Final which is habitually only
> used with a somewhat undocumented use of OOB (XEP-0066) feels a bit
> wrong, but there's technically nothing incorrect by process in doing
> so.
> 
> So what do we feel as a group?

I was going to raise similar question, even drafted the response.
because I've seen this challenge while implementing client side.
But then re-read the spec, thought it over again, and removed the
question. Because it has nothing to do with this spec.
It's more to OOB itself.

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

Re: [Standards] Call for Experience: XEP-0363: HTTP File Upload

[Ruslan N. Marchenko]

Am Dienstag, den 20.10.2020, 14:31 + schrieb Jonas Schäfer:
> The XEP Editor would like to Call for Experience with XEP-0363 before
> presenting it to the Council for advancing it to Final status.
> 
> 
> During the Call for Experience, please answer the following
> questions:
> 
> 1. What software has XEP-0363 implemented? Please note that the
> protocol must be implemented in at least two separate codebases (at
> least one of which must be free or open-source software) in order to
> advance from Draft to Final.
> 
libpurple plugin (client):
https://github.com/Junker/purple-xmpp-http-upload (by Dmitry Kosenkov)

djabberd plugin (server):
https://github.com/rufferson/DJabberd-Plugin-HTTPUpload

> 2. Have developers experienced any problems with the protocol as
> defined in XEP-0363? If so, please describe the problems and, if
> possible, suggested solutions.

No

> 
> 3. Is the text of XEP-0363 clear and unambiguous? Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate?
> Have developers found the text confusing at all? Please describe any
> suggestions you have for improving the text.

There's one sentence which is a bit ambiguous:
> Implementors should keep in mind, that without additional end-to-end-
> encryption, files uploaded to a service described in this document
> may be stored in plain text. 

Not quite clear what it tries to say, perhaps that file will be
*transferred* in a _plain text_ (unencrypted)? As end-to-end encryption
(https) has little impact on how the file is stored.

> If you have any comments about advancing XEP-0363 from Draft to
> Final,
> please provide them by the close of business on 2020-11-03. After the
> Call for Experience, this XEP might undergo revisions to address
> feedback received, after which it will be presented to the XMPP
> Council for voting to a status of Final.
> 
> 
> You can review the specification here:
> 
> https://xmpp.org/extensions/xep-0363.html
> 
> Please send all feedback to the standards@xmpp.org discussion list.
> ___
> 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] Stanza ID of outgoing message

[Ruslan N. Marchenko]

Am Montag, den 28.09.2020, 09:51 +0100 schrieb Dave Cridland:
> 
> 
> On Sun, 27 Sep 2020 at 16:46, Holger Weiß 
> wrote:
> > 
> > I think it would be good to find a better solution.
> 
> OK, just out of curiosity, why?

I for one want that to be formalized. 
So far the formal response to that problem in the XEP is mere
acknoledgement of the problem and its declaration to be out of scope.
Which invites for follow-up and resolution. The de-facto state is based
on hell lot of assumptions which are not formalized anywhere.
Message id - not mandated. Message frame storage - not mandated. To
store any data allowing the dedup - not mandated.

> 
> (2) and (3) (and your un-numbered proposal) cause both an additional
> response *and* a further '198 ack back from the client to acknowledge
> that response, which seems dramatically ugly.

It is in general off-topic but I'd expect behaving client to do
selective 198 ack (window and time based - as per 198's recommendation)
rather than blind _every stanza_, so that does not put major concern to
me.

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

Re: [Standards] Stanza ID of outgoing message

[Ruslan N. Marchenko]

Am Sonntag, den 27.09.2020, 17:45 +0200 schrieb Holger Weiß:
> When opening a new session, MAM clients might want to use the
> most-recent known XEP-0359 stanza ID to sync messages.  One problem
> they
> face is that there's no way to figure out the stanza ID of outgoing
> messages, short of actually querying them back from MAM.  Therefore,
> a
> common workaround is to use the stanza ID of the most-recent
> _incoming_
> message and then de-dup any outgoing messages returned from MAM.
> ...
> I'd prefer a solution that doesn't involve reflecting the entire
> stanza
> just to make the client aware of the stanza ID.  So if (1) is not an
> option, I think I'd opt for extending XEP-0359 or XEP-0313 (or, if
> people prefer, adding a new XEP) to return an ACK for outgoing 1:1
> messages.  E.g., something like this:
> 
> > 
> >   
> > 
> 
Yes, this sounds good but in general I'd like to know whether the
message has actually been archived by mam. Are there any other use
cases where stanza_id will be attached to the message (except mam)?
If yes (or planned) then we'd probably need mam-specific reverse id
notification. Eg.


  


under mam namespace it would actually indicate the archiving entity
handled the message under specified ID, regardless of other
requirements to the ID itself. And if MAM skips the archive it may ack
back like:


  


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

Re: [Standards] Very Simple Questions about Compliance Suites

[Ruslan N. Marchenko]

Am Mittwoch, den 02.09.2020, 16:23 +0100 schrieb Dave Cridland:
> Hey all,
> 
> Really simple questions, so please do reply and answer:
> 
> If you have an XMPP product or public project, do you claim
> compliance with XEP-0423?
> 
> If you do not claim compliance, are you aiming for compliance with
> XEP-0423?
Yes, this is clear indication of what is considered to modern features
(among 400+ extensions) so it's a good tangible goal for development
alone.

Plus it gives possibility for users to raise issues for non-compliance
(or missing features from the compliance) which they gladly do.

Compliance tool (thanks to Daniel et al.) makes it even more tangible
and together with xmpp observatory they make a good pair of badges to
achieve.
Even though compliance tool is far from being complete representation
of the 0432.

Variety of compliance standards though makes it a bit less motivating,
as one can say - ok, i'm probably not 2020 compliant because it just reached 
2019 compliance and it's still good enough for me.

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

Re: [Standards] XEP0384 OMEMO pubsub#publish-options clarification

[Ruslan N. Marchenko]

Am Samstag, den 29.08.2020, 09:15 +0200 schrieb Philipp Hörist:
> Hi,
> 
> Just to be clear, the XEP mandates protocol features, not a default
> config on your PubSub Service.
> 
> Default config does not make much sense, as other XEPs would need
> another configuration, that would mean we would need per node default
> configurations.
> 
> Publish Options solves that.
Thanks Philipp for clarification.

I'll fire up a PR to make it straight and fix the typo.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP0384 OMEMO pubsub#publish-options clarification

[Ruslan N. Marchenko]

Am Samstag, den 29.08.2020, 08:37 +0200 schrieb Philipp Hörist:
> Am Sa., 29. Aug. 2020 um 08:16 Uhr schrieb Ruslan N. Marchenko <
> m...@ruff.mobi>:
> > The way I read it initially was "pubsub service MUST support
> > persitent items" but it seems it really mandates pubsub default
> > config rather than feature support?
> 
> No, and why do you think that?
>  
Don't know, that's just how I interpreted that while reading, maybe
because all lines below mention 'support' so it blended with them.

So then my second interpretation is correct and the document really
requires certain server *settings* rather than protocol/feature
support?

> > Then "'max' as value to persisy_items" I persume is a typo and
> > should read as 'max' value to 'max_items' when used together with
> > 'persist_items'?
> > 
> > 
> 
> Yes is a typo, should be fixed
>  
> > After I implemented publish-options, configure-node, persist-items, 
> > multi-items, delete-items (and retract-item which seem to be
> > redundant) I still see the omemo merely sets access-model to open
> > (as in XEP's example) but not others.
> 
> What do you mean by "omemo merely sets .." what is omemo in that
> context?
The "omemo client implementation", thne one below, 
>  
> > And since my default pep node config is no persist, max 1,
> > pam=presence it only flips pam to open and the rest remains as is
> > (no persistence, max=1). 
> > Is it just conversations specific or the XEP really mandates
> > defaults on the PEP node? It should be fairly easy to set the rest
> > of the required options in publish options instead of mandating the
> > defaults.
> 
> Conversations does not implement the XEP version you are referring
> to, maybe that answers your question.
> 

Ok, yes that would explain.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP0384 OMEMO pubsub#publish-options clarification

[Ruslan N. Marchenko]

Am Samstag, den 08.08.2020, 09:22 +0200 schrieb Philipp Hörist:
> Hi,
> 
> Note that major server implementation don’t support checking all
> fields they support with publish-options
> 
> Means only because a server supports max_items, it does not mean it
> can check the value via publish-options.
> 
Ok, thanks for the hint, although I've implemented all preconditions
checks, will see how far it goes.

But I still have a question regarding OMEMO and publish-options,
In XEP-0384 7.1 it mentions:
 * The pubsub service MUST persist node items.
 * The pubsub service MUST support publishing options as defined
in XEP-0060 §7.1.5.
 * The pubsub service MUST support 'max' as a value for the
'pubsub#persist_items' node configuration.
 * The pubsub service MUST support the 'open' access model for node
configuration and 'pubsub#access_model' as a publish option.
The way I read it initially was "pubsub service MUST support persitent
items" but it seems it really mandates pubsub default config rather
than feature support?
Then "'max' as value to persisy_items" I persume is a typo and should
read as 'max' value to 'max_items' when used together with
'persist_items'?

After I implemented publish-options, configure-node, persist-items,
multi-items, delete-items (and retract-item which seem to be redundant)
I still see the omemo merely sets access-model to open (as in XEP's
example) but not others.
And since my default pep node config is no persist, max 1, pam=presence
it only flips pam to open and the rest remains as is (no persistence,
max=1). 
Is it just conversations specific or the XEP really mandates defaults
on the PEP node? It should be fairly easy to set the rest of the
required options in publish options instead of mandating the defaults.

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

Re: [Standards] XEP0384 OMEMO pubsub#publish-options clarification

[Ruslan N. Marchenko]

Am Samstag, den 08.08.2020, 07:13 + schrieb Daniel Gultsch:
> Am Sa., 8. Aug. 2020 um 07:07 Uhr schrieb Ruslan N. Marchenko <
> m...@ruff.mobi>:
> > 
> > I.e. I know the form can contain any arbitrary data just wonder if
> > any
> > implementation applies some additional validation of the publish
> > options which may lead to iq errors. Or if such options would
> > simply be
> > ignored and needs to be done via additional node configration
> > roundtrip?
> > 
> 
> Quoting XEP-0060 here:
> 
> > A pub-sub service advertising support for publishing options MUST
> > check each precondition field against the node configuration of the
> > same name, and it MUST reject the publication upon encountering
> > unknown fields.
> 
> *of the same name*. This means the publish option doesn’t need to be
> registered. Just the node configuration field.
> 
Thanks for clarification, this registry thingy was a bit confusing and
just blocked my attempt to search for any further [free text]
validation rules.


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

[Standards] XEP0384 OMEMO pubsub#publish-options clarification

[Ruslan N. Marchenko]

Hi Standards,

I'm trying to extend PEP server implementation to support OMEMO and
stumbled upon following issue: the OMEMO 5.3.2 stipulates the max_items
should be specified in the publish-options form, however neither form
registry nor XEP-0060 allow anything but access-model in the publishing
options.

Is it my mis-interpretation of the form registry enforcement or OMEMO
needs to add a statement that it is going to extend the registery with
additional fields?

I.e. I know the form can contain any arbitrary data just wonder if any
implementation applies some additional validation of the publish
options which may lead to iq errors. Or if such options would simply be
ignored and needs to be done via additional node configration
roundtrip?

--rr

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

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

[Ruslan N. Marchenko]

Am Dienstag, den 04.08.2020, 16:05 + schrieb XEP Editor Pipeline:
> This message constitutes notice of a Last Call for comments on
> XEP-0352.
> 
> Title: Client State Indication
> Abstract:
> This document defines a way for the client to indicate its
> active/inactive state.
> 
> URL: https://xmpp.org/extensions/xep-0352.html
> 
> This Last Call begins today and shall end at the close of business on
> 2020-08-18.
> 
> 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?
> 
Yes
> 2. Does the specification solve the problem stated in the
> introduction
> and requirements?
> 
Yes
> 3. Do you plan to implement this specification in your code? If not,
> why not?
> 
Yes, implemented in client and server stacks
> 4. Do you have any security concerns related to this specification?
> 
No
> 5. Is the specification accurate and clearly written?
> 
Yes
> Your feedback is appreciated!
> ___
> 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] NEW: XEP-0440 (SASL Channel-Binding Type Capability)

[Ruslan N. Marchenko]

Am Dienstag, den 21.07.2020, 19:28 +0100 schrieb Dave Cridland:
> On Tue, 21 Jul 2020 at 18:57, Florian Schmaus 
> wrote:
> > Based on the discussion in this thread, I suggest the following
> > changes
> > 
> > 
> > 
> > http://geekplace.eu/xeps/xep-sasl-cb-types/diff.html#sasl-mech-interaction
> 
> Is it worth making tls-server-endpoint an MTI for XEP-0440?
> 
> 
> It is, as you note, trivial to implement, and as we always chant, MTI
> is Mandatory to Implement, not Mandatory to Deploy.
> 
> But it means anything using XEP-0440 MUST implement (and PROBABLY
> SHOULD deploy) a common binding that's reasonably well understood,
> provides some  significant protection, and is easy to implement. If
> it turns out we really need something better later, we can review and
> change the MTI.
> 
> It also means that if it is not offered, one assumes the server
> administrator has some very good reasons for doing so.
> 
I'd second that. The main driver for this xep I believe is to break the
tie of the tls-unique'ness which by various factors became the one and
only commonly accepted and utterly broken binding mechanism (I hear the
conspiracy whispers).  And to make other mechanisms possible by being
negotiable. 
tls-server-end-point on the other hand while being susceptible to pre-
image attacks is still laughably easy to implement and provides decent
'better-than-nothing' security.
--rr
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0440 (SASL Channel-Binding Type Capability)

[Ruslan N. Marchenko]

Am Donnerstag, den 16.07.2020, 13:08 +0200 schrieb Ruslan N. Marchenko:
> Am Donnerstag, den 16.07.2020, 10:33 + schrieb Daniel Gultsch:
> > Am Do., 16. Juli 2020 um 10:13 Uhr schrieb Florian Schmaus <
> > f...@geekplace.eu>:
> > 
> > > If you send 'y', which implies that you, the client, did not
> > > select
> > > a
> > > -PLUS mechanism for authentication, while the server announces at
> > > least
> > > one SCRAM-*-PLUS mechanism, then the server may suspect a MitM
> > > attack
> > > and terminates the connection.
> > 
> > Yes. But that's the desired behaviour, no?
> Desired by MitM, yes :)

Sorry I misread (and misinterpreted) the comment as to say n is desired
behaviour.
Yes, y is would be kind of safest but sending y when both sides know
-PLUS is there is as good as client just aborts the connection. Which
could be an option actually.

> I'd rather suggest if no matching methods are found just ignore the
> the
> hint and do tls-unique (as you would do in absence of this method) or
> any other method you support instead in local preference order (eg
> tls-
> exporter, then tsl-server-end-point, etc.).
> 
> --rr
> 
> ___
> 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] NEW: XEP-0440 (SASL Channel-Binding Type Capability)

[Ruslan N. Marchenko]

Am Donnerstag, den 16.07.2020, 10:33 + schrieb Daniel Gultsch:
> Am Do., 16. Juli 2020 um 10:13 Uhr schrieb Florian Schmaus <
> f...@geekplace.eu>:
> 
> > If you send 'y', which implies that you, the client, did not select
> > a
> > -PLUS mechanism for authentication, while the server announces at
> > least
> > one SCRAM-*-PLUS mechanism, then the server may suspect a MitM
> > attack
> > and terminates the connection.
> 
> Yes. But that's the desired behaviour, no?
Desired by MitM, yes :)
I'd rather suggest if no matching methods are found just ignore the the
hint and do tls-unique (as you would do in absence of this method) or
any other method you support instead in local preference order (eg tls-
exporter, then tsl-server-end-point, etc.).

--rr

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

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Ruslan N. Marchenko]

Am Dienstag, den 31.03.2020, 20:38 + schrieb Jonas Schäfer:
> This message constitutes notice of a Last Call for comments on
> XEP-0280.
> 
> Title: Message Carbons
> Abstract:
> In order to keep all IM clients for a user engaged in a conversation,
> outbound messages are carbon-copied to all interested resources.
> 
> URL: https://xmpp.org/extensions/xep-0280.html
> 
> This Last Call begins today and shall end at the close of business on
> 2020-04-08.
> 
> 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?
> 
I know it is expired LC and I have answered to this or previous one but
I have a question, now that I'm adding some unit-tests to the
implementation.
The sections 7 & 8 are referring to RFC 6121 for message delivery and
mentions the CC should be after delivery. In 7 kind of implicitly, in 8
ambiguous, 'and' could mean 'and then' or 'and also'. The question is -
what happens for unsuccessful delivery in 8, where often we don't even
know whether delivery will ever succeed (eg s2s fails). 

There's last sentence in first abstract of section 8 saying "Note that
this happens irrespective of whether the sending client has carbons
enabled." - should it be expanded with "and whether delivery for the
sent message succeeds."? Which would mean for 8 we CC on incoming
message on c2s (and for 7 on delivery completion as it is now).
My current implementation is actually doing both on delivery completion
but unit test fails because temporary test instance does not have s2s
(could be done but too much pre-staging for a simple test).
--rr

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

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

[Ruslan N. Marchenko]

Am Donnerstag, den 09.07.2020, 11:27 +0100 schrieb Dave Cridland:
> On Wed, 8 Jul 2020 at 12:44, Ruslan N. Marchenko 
> wrote:
> > Am Dienstag, den 07.07.2020, 10:55 +0100 schrieb Dave Cridland:
> > > If Alice connects and authenticates Bob via some means, and Bob
> > > authenticates Alice by some means, what does it matter to Alice
> > > how Bob authenticates Alice, or vice-versa?
> > > 
> > > Your statement is that there is a potential downgrade attack
> > > here; my assertion is that there is not.
> > > 
> > > Could you please describe:
> > > 
> > > a) What the attacker gains.
> > > b) How the attacker carries out the attack.
> > a) full control over XMPP stream
> > b) If Alice's key is compromised (forged or stolen) and Alice's
> > server is fronted by MitM proxy - then Bob's certificate becomes
> > the only mean to protect the integrity/confidentiality of the Bob-
> > to-Alice communication - since Bob's key is still protected,
> > Alice's refusal to accept it causes attacker to achieve nothing.
> > But as I have previously mentioned since Bob follows features
> > section, and features section is only protected by Alice's key
> > (which is compromised) the change in the EXTERNAL behaviour does
> > nothing as EXTERNAL in the case can be eliminated by an attacker by
> > stripping it from the stream features.
> > 
> > 
> 
> OK, let me see if I understand this:
> 
> Alice (a server) calls Bob (another server). We shall assume that
> Alice requires TLS, and will strictly verify the certificate against
> a known trust anchor, and require that Bob's name be present - that
> is, gold-standard TLS policy. We assume that Bob might not have such
> a policy.
> 
> Bob offers, and Alice negotiates, TLS. Both sides provide a
> certificate (and the requisite signing to prove ownership of the
> private keys. At *this* point:
> 
> * Alice has proof of Bob's certificate, and chooses to trust it. This
> proves to Alice that she is genuinely talking to Bob.
> * Bob accepts Alice's certificate, but does not consider it
> sufficient for authentication for some reason.
> 
> Alice then opens a new stream.
> 
> Bob offers EXTERNAL. This offer is, from Alice's perspective, secure.
> 
> Alice issues EXTERNAL.
> 
> Bob does not trust Alice's certificate even after EXTERNAL, and
> continues the connection.
> 
> Alice requests Dialback.
> 
> Bob does some form of Dialback (XEP-0344 or simple XEP-0220).
> 
> Now, at this point, is your assertion that Alice can be actually
> talking to an attacker, and not Bob?
> 
> Bob, I agree, might not be talking to Alice (depending on how clever
> Bob has been with XEP-0344, this might be very unlikely though). But
> that is wholly under the control of Bob; Alice's security posture is
> entirely unaffected.
> 
> You seem to suggest that the attack is based on Alice's key being
> compromised; but if this is so I do not understand what has changed
> here - if the key is compromised that obviously an attacker can
> impersonate Alice - in fact, an attacker can impersonate Alice more
> easily if a pure SASL EXTERNAL is used than if Dialback is used in
> conjunction.
>  

With dialback the integrity of the channel is not enforced therefore an
attacker being able to intercept the communication (front the server
with compromised certificate) can simply pass through the messages
waiting for authentication to complete and then "take the control
back".
Mutual TLS authentication (achieved with EXTERNAL mechanism) though
puts integrity verification similar to TLS channel bindings for SASL -
therefore the integrity is verified on both sides. An attacker won't be
able to forge Bob's certificate, so if EXTERNAL is requested an
attacker can authenticate itself for Bob as Alice (impersonate) but he
won't be able to impersonate himself to Alice as Bob.
I apologize but it seems I have swapped the roles in my example
comparing to your suggested setup.

The attack setup is following - Bob (server1) connecting to Alice
(server2) which is impersonated by an Attacker (MitM proxy with Alice's
compromised certificate).
XEP-0178 currently mandates Alice (server2) to close the stream if
Bob's (server1) auth fails (identity mismatch).  Eg. if an attacker
puts his certificate to Alice but preserves Bob's 'from' header to
maintain s2s routing for Bob - Alice rejects that connection.
Proposed change is for Alice to ignore that error and switch to
dialback on the same established channel which would allow an attacker
to maintain the control over the stream.

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

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

[Ruslan N. Marchenko]

Am Dienstag, den 07.07.2020, 10:55 +0100 schrieb Dave Cridland:
> On Mon, 6 Jul 2020 at 15:41, Ruslan N. Marchenko 
> wrote:
> > Am Montag, den 06.07.2020, 16:20 +0200 schrieb Ruslan N. Marchenko:
> > > Am Montag, den 06.07.2020, 13:19 +0100 schrieb Dave Cridland:
> > > > On Mon, 6 Jul 2020 at 12:44, Ruslan N. Marchenko 
> > > > wrote:
> > > > > Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland:
> > > > > > On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko <
> > > > > > m...@ruff.mobi> wrote:
> > > > > > > Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave
> > > > > > > Cridland:
> > > > > > > > On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko <
> > > > > > > > m...@ruff.mobi> wrote:
> > > > > > > > > Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave
> > > > > > > > > Cridland:
> > > > > > > > > > >  it cannot establish partially where one side
> > > > > > > > > > > trusts (authenticates) and other does not.
> > > > > > > > > > 
> > > > > > > > > > You can very much establish a TLS session where one
> > > > > > > > > > side authenticates by the certificate presented but
> > > > > > > > > > the other side does not.
> > > > > > > > > Not if you mandate mutual TLS auth (request cert)
> > > > > > > > 
> > > > > > > > "Mutual authentication" means both sides authenticating
> > > > > > > > the other in the same action. Here, both sides can
> > > > > > > > authenticate the other, but need not. Either side is
> > > > > > > > entirely free to ignore the certificate for any number
> > > > > > > > of reasons. (The confusion arises because all SASL
> > > > > > > > mechanisms that support server authentication are by
> > > > > > > > definition mutual authentication).
> > > > > > > Yes, this is exactly the point. But not only that, by
> > > > > > > mandating SASL external over TLS you also mandate TLS
> > > > > > > mutual authentication (which happens within the same
> > > > > > > protected channel).
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > Ah, no. Because SASL EXTERNAL isn't an authentication at
> > > > > > all, there's no implication of mutual authentication (and
> > > > > > often isn't any bidirectional either).
> > > > > Maybe I'm not aware of other uses of EXTERNAL auth but when I
> > > > > wanted to implement EXTERNAL support in XMPP to advertise it
> > > > > in mechanisms and expect interoperability with other
> > > > > client/servers I need to request client certificate
> > > > > (set_verify_mode VERIFY_PEER) and then validate received
> > > > > certificate. If that is not mutual TLS auth then I'm not sure
> > > > > what that is.
> > > > 
> > > > It's client authentication.
> > 
> > Also. Server authentication + client authentication = Mutual
> > Authentication.
> > 
> > 
> 
> Normally, "mutual authentication" means both sides have assured that
> the other is authenticated *and* has authenticated them. For example,
> SCRAM and DIGEST both have the server provide proof that the server
> also knows the secret used by the client. That's not the case with
> TLS's use of X.509 - each authentication is unidirectional and
> independent.
> 
It is not, both sides need to have private key in order to complete
identification, and client certificate authentication is executed
within server's security context (RFC 5246 7.4.4 Note: It is a fatal
handshake_failure alert for an anonymous server to request client
authentication).
 
You cannot just pick random public key (certificate) and offer it in
TLS CertificateRequest message because there is CertificateVerify
message which requires you to have access to the private key whith
which you need to sign entire handshake (security context). It *is* TLS
authentication.

But yes, you can set a policy where you accept any security context
from the server (pseudo-anonymous) and authentication only client. Or
you can skip CertificateRequest (default state) and authenticate only
server. But when you do RequestCe

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

[Ruslan N. Marchenko]

Am Montag, den 06.07.2020, 16:20 +0200 schrieb Ruslan N. Marchenko:
> Am Montag, den 06.07.2020, 13:19 +0100 schrieb Dave Cridland:
> > On Mon, 6 Jul 2020 at 12:44, Ruslan N. Marchenko 
> > wrote:
> > > Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland:
> > > > On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko 
> > > > wrote:
> > > > > Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave
> > > > > Cridland:
> > > > > > On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko <
> > > > > > m...@ruff.mobi> wrote:
> > > > > > > Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave
> > > > > > > Cridland:
> > > > > > > > >  it cannot establish partially where one side trusts
> > > > > > > > > (authenticates) and other does not.
> > > > > > > > 
> > > > > > > > You can very much establish a TLS session where one
> > > > > > > > side authenticates by the certificate presented but the
> > > > > > > > other side does not.
> > > > > > > Not if you mandate mutual TLS auth (request cert)
> > > > > > 
> > > > > > "Mutual authentication" means both sides authenticating the
> > > > > > other in the same action. Here, both sides can authenticate
> > > > > > the other, but need not. Either side is entirely free to
> > > > > > ignore the certificate for any number of reasons. (The
> > > > > > confusion arises because all SASL mechanisms that support
> > > > > > server authentication are by definition mutual
> > > > > > authentication).
> > > > > Yes, this is exactly the point. But not only that, by
> > > > > mandating SASL external over TLS you also mandate TLS mutual
> > > > > authentication (which happens within the same protected
> > > > > channel).
> > > > > 
> > > > > 
> > > > 
> > > > Ah, no. Because SASL EXTERNAL isn't an authentication at all,
> > > > there's no implication of mutual authentication (and often
> > > > isn't any bidirectional either).
> > > Maybe I'm not aware of other uses of EXTERNAL auth but when I
> > > wanted to implement EXTERNAL support in XMPP to advertise it in
> > > mechanisms and expect interoperability with other client/servers
> > > I need to request client certificate (set_verify_mode
> > > VERIFY_PEER) and then validate received certificate. If that is
> > > not mutual TLS auth then I'm not sure what that is.
> > 
> > It's client authentication.

Also. Server authentication + client authentication = Mutual
Authentication.
X509 based TLS is Server Auth. VERIFY_PEER requests CLient Auth - both
together are mutual x509 TLS Auth.
XMPP over TLS uses x509 TLS and thus Server Auth. SASL EXTERNAL
requests Client x509 cert and thus Client Auth. Both together achieve
Mutual Auth. It does not tell how you validate or verify certificate
validity (which is your *policy*) only how to request Client auth and
how to obtain authenticated client's and server's identity from the
wire protocol.
> > You can do this whether you have a certificate or not yourself -
> > though it's fair to say if you don't have a certificate, then very
> > few clients or initiating servers will talk to you at all.
> > 
> > But you absolutely can do this with a self-signed certificate.
> > Whether anyone connects to you at *that* point is a matter of their
> > policy, not yours.
> >  
> Sorry I don't follow you here. _How_ you trust the certificate is
> your *policy* . The fact that a party *must* have a certificated
> trusted by your policy is authentication.
> 
> If I am Bob and I trust Alice's certificate, but Alice doesn't trust
> mine - could be a policy thing of course. Because Alice may only
> accepted certificates issued by hereself or signed by her boyfriend.
> It's her decision. But it's a closed system. 
> In open system TLS validation [policy] is pretty much written down
> and fixed in 13.7.2 (eg 13.7.2.2.1) and if I follow this *policy*
> while connecting to open system and that opens system doesn't trust
> myself I have two conclusions - either it is misconfigured or it
> doesn't actually see *my* certificate but rather someone else's.
> Especially this is valid if we are part of closed system and my
> certificate was signed by Alice's boyfriend.
> 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

[Ruslan N. Marchenko]

Am Montag, den 06.07.2020, 13:19 +0100 schrieb Dave Cridland:
> On Mon, 6 Jul 2020 at 12:44, Ruslan N. Marchenko 
> wrote:
> > Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland:
> > > On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko 
> > > wrote:
> > > > Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland:
> > > > > On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko <
> > > > > m...@ruff.mobi> wrote:
> > > > > > Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave
> > > > > > Cridland:
> > > > > > > >  it cannot establish partially where one side trusts
> > > > > > > > (authenticates) and other does not.
> > > > > > > 
> > > > > > > You can very much establish a TLS session where one side
> > > > > > > authenticates by the certificate presented but the other
> > > > > > > side does not.
> > > > > > Not if you mandate mutual TLS auth (request cert)
> > > > > 
> > > > > "Mutual authentication" means both sides authenticating the
> > > > > other in the same action. Here, both sides can authenticate
> > > > > the other, but need not. Either side is entirely free to
> > > > > ignore the certificate for any number of reasons. (The
> > > > > confusion arises because all SASL mechanisms that support
> > > > > server authentication are by definition mutual
> > > > > authentication).
> > > > Yes, this is exactly the point. But not only that, by mandating
> > > > SASL external over TLS you also mandate TLS mutual
> > > > authentication (which happens within the same protected
> > > > channel).
> > > > 
> > > > 
> > > 
> > > Ah, no. Because SASL EXTERNAL isn't an authentication at all,
> > > there's no implication of mutual authentication (and often isn't
> > > any bidirectional either).
> > Maybe I'm not aware of other uses of EXTERNAL auth but when I
> > wanted to implement EXTERNAL support in XMPP to advertise it in
> > mechanisms and expect interoperability with other client/servers I
> > need to request client certificate (set_verify_mode VERIFY_PEER)
> > and then validate received certificate. If that is not mutual TLS
> > auth then I'm not sure what that is.
> 
> It's client authentication.
> 
> You can do this whether you have a certificate or not yourself -
> though it's fair to say if you don't have a certificate, then very
> few clients or initiating servers will talk to you at all.
> 
> But you absolutely can do this with a self-signed certificate.
> Whether anyone connects to you at *that* point is a matter of their
> policy, not yours.
>  
Sorry I don't follow you here. _How_ you trust the certificate is your
*policy* . The fact that a party *must* have a certificated trusted by
your policy is authentication.
If I am Bob and I trust Alice's certificate, but Alice doesn't trust
mine - could be a policy thing of course. Because Alice may only
accepted certificates issued by hereself or signed by her boyfriend.
It's her decision. But it's a closed system. In open system TLS
validation [policy] is pretty much written down and fixed in 13.7.2 (eg
13.7.2.2.1) and if I follow this *policy* while connecting to open
system and that opens system doesn't trust myself I have two
conclusions - either it is misconfigured or it doesn't actually see
*my* certificate but rather someone else's. Especially this is valid if
we are part of closed system and my certificate was signed by Alice's
boyfriend.
> > >  
> > > > Nevertheless I just realized the whole mechanism proposal part
> > > > is not protected by the SASL so any ill-minded adversary can
> > > > easily suppress EXTERNAL and enjoy dialback-only. So based on
> > > > that I recall my downgrade statement - the attack vector
> > > > requires level of exposure (TLS airgap with trusted
> > > > certificate) which invalidates the whole mechanism and thus any
> > > > imposed by it identity/confedentiality protection.
> > > 
> > > So you now think that SASL EXTERNAL as a whole is subject to some
> > > kind of downgrade attack?
> > > 
> > > Could you please explain this, because it sounds entirely wrong
> > > to me. 
> > > 
> > No, external is not a downgrade. Just to make (ab)use of external
> > dowgraded to dialback you need level of interception which makes
> > dowgrade by the PR in scope redundant as you can achieve the same
> > outcome (dialback) regardless of whether the external behaves as in
> > current XEP0178 edition or as in proposed modified one.
> 
> Ah, OK. Still not a downgrade, as Alice can still authenticate Bob in
> exactly the same way, and to suppress EXTERNAL you'd need an
> integrity attack against the session, which'd currently be heavily
> mitigated by Alice having authenticated Bob's certificate.
> 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

[Ruslan N. Marchenko]

Am Montag, den 06.07.2020, 10:46 +0100 schrieb Dave Cridland:
> On Sun, 5 Jul 2020 at 22:13, Ruslan N. Marchenko 
> wrote:
> > Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland:
> > > On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko 
> > > wrote:
> > > > Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave Cridland:
> > > > > On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko <
> > > > > m...@ruff.mobi> wrote:
> > > > > > Because Alice's authentication fails on this particualr
> > > > > > conneciton? So it may be not Alice after all speaking,
> > > > > > despite what 'from' tells (or does not). From Bob's
> > > > > > perspective someone tries to spoof Alice's server over this
> > > > > > connection.
> > > > > 
> > > > > The question isn't whether it's a bad decision by Bob or
> > > > > not, but whether it's an active downgrade. Metre, FWIW,
> > > > > ditches you if you try to provide an authzid that differs
> > > > > from the stream "from", but it will, I think, allow you to
> > > > > continue if you provide no stream "from" and are using, for
> > > > > example, a wildcard cert, so there is no implicit authzid
> > > > > available to it. 
> > > > > > > Alice, on the other hand, has already either decided to
> > > > > > > trust Bob's certificate or not. Nothing Bob does at this
> > > > > > > point affects that decision in the slightest, nor alters
> > > > > > > the security outcome of the decision already made. So
> > > > > > > there is no downgrade attack on Alice here.
> > > > > > 
> > > > > > The EXTERNAL TLS  is mutual authentication,
> > > > > 
> > > > > EXTERNAL, with or without TLS, is absolutely not in any way
> > > > > mutual authentication. EXTERNAL isn't authentication at all,
> > > > > actually.
> > > > 
> > > > Now this is nit picking. STARTTLS is not a TLS but is a way to
> > > > secure connection with TLS encryption, EXTERNAL is not an
> > > > authentication but is a way to execute mutual TLS x509
> > > > authentication.
> > > > 
> > > > 
> > > 
> > > The former would be nitpicking; the latter is not.
> > > 
> > > In S2S, there are two independent authentications going on, and
> > > by the time the initiator (Alice) issues EXTERNAL, it should have
> > > already completed its authentication of Bob (and Bob should have
> > > at least decided to trust the certificate before offering
> > > EXTERNAL, with just name matching to go).
> > > 
> > > If Bob rejects EXTERNAL but continues, Alice still knows Bob is
> > > the correct server. Just that Bob hasn't accepted the
> > > certificate.
> > > 
> > > The only reason for Bob to then close the session is if Bob
> > > *only* accepts TLS authentication, and moreover cannot handle
> > > XEP-0344§2.4. The former is perfectly acceptable, of course, and
> > > might even be desirable - but it's not something I feel needs
> > > mandating by inference here.
> > >  
> > > > >  
> > > > > >  it cannot establish partially where one side trusts
> > > > > > (authenticates) and other does not.
> > > > > 
> > > > > You can very much establish a TLS session where one side
> > > > > authenticates by the certificate presented but the other side
> > > > > does not.
> > > > Not if you mandate mutual TLS auth (request cert)
> > > 
> > > "Mutual authentication" means both sides authenticating the other
> > > in the same action. Here, both sides can authenticate the other,
> > > but need not. Either side is entirely free to ignore the
> > > certificate for any number of reasons. (The confusion arises
> > > because all SASL mechanisms that support server authentication
> > > are by definition mutual authentication).
> > Yes, this is exactly the point. But not only that, by mandating
> > SASL external over TLS you also mandate TLS mutual authentication
> > (which happens within the same protected channel).
> > 
> > 
> 
> Ah, no. Because SASL EXTERNAL isn't an authentication at all, there's
> no implication of mutual authentication (and often isn't any
> bidirectional eit

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

[Ruslan N. Marchenko]

Am Samstag, den 04.07.2020, 19:47 +0100 schrieb Dave Cridland:
> On Thu, 2 Jul 2020 at 06:58, Ruslan N. Marchenko 
> wrote:
> > Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave Cridland:
> > > On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko 
> > > wrote:
> > > > Because Alice's authentication fails on this particualr
> > > > conneciton? So it may be not Alice after all speaking, despite
> > > > what 'from' tells (or does not). From Bob's perspective someone
> > > > tries to spoof Alice's server over this connection.
> > > 
> > > The question isn't whether it's a bad decision by Bob or not, but
> > > whether it's an active downgrade. Metre, FWIW, ditches you if you
> > > try to provide an authzid that differs from the stream "from",
> > > but it will, I think, allow you to continue if you provide no
> > > stream "from" and are using, for example, a wildcard cert, so
> > > there is no implicit authzid available to it. 
> > > > > Alice, on the other hand, has already either decided to trust
> > > > > Bob's certificate or not. Nothing Bob does at this point
> > > > > affects that decision in the slightest, nor alters the
> > > > > security outcome of the decision already made. So there is no
> > > > > downgrade attack on Alice here.
> > > > 
> > > > The EXTERNAL TLS  is mutual authentication,
> > > 
> > > EXTERNAL, with or without TLS, is absolutely not in any way
> > > mutual authentication. EXTERNAL isn't authentication at all,
> > > actually.
> > 
> > Now this is nit picking. STARTTLS is not a TLS but is a way to
> > secure connection with TLS encryption, EXTERNAL is not an
> > authentication but is a way to execute mutual TLS x509
> > authentication.
> > 
> > 
> 
> The former would be nitpicking; the latter is not.
> 
> In S2S, there are two independent authentications going on, and by
> the time the initiator (Alice) issues EXTERNAL, it should have
> already completed its authentication of Bob (and Bob should have at
> least decided to trust the certificate before offering EXTERNAL, with
> just name matching to go).
> 
> If Bob rejects EXTERNAL but continues, Alice still knows Bob is the
> correct server. Just that Bob hasn't accepted the certificate.
> 
> The only reason for Bob to then close the session is if Bob *only*
> accepts TLS authentication, and moreover cannot handle XEP-0344§2.4.
> The former is perfectly acceptable, of course, and might even be
> desirable - but it's not something I feel needs mandating by
> inference here.
>  
> > >  
> > > >  it cannot establish partially where one side trusts
> > > > (authenticates) and other does not.
> > > 
> > > You can very much establish a TLS session where one side
> > > authenticates by the certificate presented but the other side
> > > does not.
> > Not if you mandate mutual TLS auth (request cert)
> 
> "Mutual authentication" means both sides authenticating the other in
> the same action. Here, both sides can authenticate the other, but
> need not. Either side is entirely free to ignore the certificate for
> any number of reasons. (The confusion arises because all SASL
> mechanisms that support server authentication are by definition
> mutual authentication).
Yes, this is exactly the point. But not only that, by mandating SASL
external over TLS you also mandate TLS mutual authentication (which
happens within the same protected channel).

Nevertheless I just realized the whole mechanism proposal part is not
protected by the SASL so any ill-minded adversary can easily suppress
EXTERNAL and enjoy dialback-only. So based on that I recall my
downgrade statement - the attack vector requires level of exposure (TLS
airgap with trusted certificate) which invalidates the whole mechanism
and thus any imposed by it identity/confedentiality protection.

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

Re: [Standards] NEW: XEP-0440 (SASL Channel-Binding Type Capability)

[Ruslan N. Marchenko]

Am Donnerstag, den 02.07.2020, 17:37 +0200 schrieb Florian Schmaus:
> On 7/2/20 1:26 PM, Ruslan N. Marchenko wrote:
> > Am Donnerstag, den 02.07.2020, 11:23 +0200 schrieb Florian Schmaus:
> > > I am not sure if this is a downgrade attack (at least a full-
> > > blown),
> > > or,
> > > if it is, if it. Without xep440 the client would have send 'p' in
> > > the
> > > case you described, with a channel-binding type not supported by
> > > the
> > > server and hence SASL authentication would fail.
> > > 
> > yes if server does not support tls unique - yes (which is mandatory
> > to
> > support), fat chance. Known issue.
> 
> Some implementations only support tls-server-end-point and not
> tls-unique, even though the latter is mandatory to implement. But in
> reality, it is often impossible to get the data required for tls-
> unique
> from the TLS stack, or at least it is far easier to get the data for
> tls-server-end-point.
> 
> 
Yes, I have also faced with that and was looking forward for this XEP
to do exactly that, but then I reconsidered and better submitted
upstream patches to include bindings retrieval api.


> 
> I think this is ultimately an issue on the SASL layer, and not
> necessarily in xep440. Clients are free to ignore the xep440
> information.
> 
The issue is rather with channel bidning selection and definition, 5056
defined one approach, then 5929 redefined another, in the end the whole
binding thing became futile. Hopefully Sam's proposal will be properly
reviewed and accepted to enforce new clealry defined defaults (101st
standard :) ).

> A pragmatic middle-ground, which mitigates the impact of the
> downgrade
> attack vector you described, would be if clients remember and pin the
> announced and used SASL mechanisms and channel-binding types (This
> may
> be a good recommendation for certain setups irregardless of xep440
> anyway.).
> 
> The security section of xep440 should definitely discuss the
> downgrade
> attack vector you described and potentially recommend SASL mechanism
> and
> channel-binding type pinning as mitigation.
> 
Pinning or even better server side signature of the features section
(another hmac) similar to but outside of sasl. Need to think of what
could be selected as reliable but well protected shared secret then.
maybe again PKDF2 derived key from authenticated credentials.

--rr

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

Re: [Standards] NEW: XEP-0440 (SASL Channel-Binding Type Capability)

[Ruslan N. Marchenko]

Am Donnerstag, den 02.07.2020, 11:23 +0200 schrieb Florian Schmaus:
> 
> I am not sure if this is a downgrade attack (at least a full-blown),
> or,
> if it is, if it. Without xep440 the client would have send 'p' in the
> case you described, with a channel-binding type not supported by the
> server and hence SASL authentication would fail.
> 
yes if server does not support tls unique - yes (which is mandatory to
support), fat chance. Known issue.

The point is - if we send n - it is a downgrade, because what happens
now is:
Me: 

Server: SCRAM-SHA-512-PLUS SCRAM-SHA-
512

MITM: SCRAM-SHA-512

Me: y,,n=me,r=blah

Server: 

any modification of the challenge (eg to swap my y with n) is protected
by hmac so will cause failure.

But now:

Server: SCRAM-SHA-512-PLUS SCRAM-SHA-
512

MITM: SCRAM-SHA-512-PLUS SCRAM-SHA-
512

Me (what?!?!, ok): n,,n=me,r=blah

Server: 

MITM: thanks man, now I'll take it from
here

> We could say xep440 modifies the semantic of the 'n' value of the
> gs2-cbind-flag from
> 
> "n" -> client doesn't support channel binding.
> 
> to
> 
> "n" -> client doesn't support any channel binding announced/supported
> by
>the server.
> 
> 

Like submit a change to IETF or something? Ideally it should be
y=dGxzLXVuaXF1ZS1mb3ItdGVsbmV0LHRscy1zZXJ2ZXItZW5kLXBvaW50Cg
- b64(tls-unique-for-telnet,tls-server-end-point) - eg I hear you but i
don't support that stuff.


> Maybe there are other options, like extending the gs2 header with a
> flag
> that explicitly states that the client believes that there are no
> mutual
> supported channel-binding types by client and server.
> 
Yes, all the negotiation should be part of the exchange signed by hmac,
otherwise you can manipulate security context from outside of security
context.

> But right now, I lean towards explicitly stating in xep440 that the
> semantic of 'n' is modified in the way I mentioned above.


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

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

[Ruslan N. Marchenko]

Am Mittwoch, den 01.07.2020, 22:53 +0100 schrieb Dave Cridland:
> On Wed, 1 Jul 2020 at 17:31, Ruslan N. Marchenko 
> wrote:
> > Because Alice's authentication fails on this particualr conneciton?
> > So it may be not Alice after all speaking, despite what 'from'
> > tells (or does not). From Bob's perspective someone tries to spoof
> > Alice's server over this connection.
> 
> The question isn't whether it's a bad decision by Bob or not, but
> whether it's an active downgrade. Metre, FWIW, ditches you if you try
> to provide an authzid that differs from the stream "from", but it
> will, I think, allow you to continue if you provide no stream "from"
> and are using, for example, a wildcard cert, so there is no implicit
> authzid available to it. 
> > > Alice, on the other hand, has already either decided to trust
> > > Bob's certificate or not. Nothing Bob does at this point affects
> > > that decision in the slightest, nor alters the security outcome
> > > of the decision already made. So there is no downgrade attack on
> > > Alice here.
> > 
> > The EXTERNAL TLS  is mutual authentication,
> 
> EXTERNAL, with or without TLS, is absolutely not in any way mutual
> authentication. EXTERNAL isn't authentication at all, actually.

Now this is nit picking. STARTTLS is not a TLS but is a way to secure
connection with TLS encryption, EXTERNAL is not an authentication but
is a way to execute mutual TLS x509 authentication.
>  
> >  it cannot establish partially where one side trusts
> > (authenticates) and other does not.
> 
> You can very much establish a TLS session where one side
> authenticates by the certificate presented but the other side does
> not.
Not if you mandate mutual TLS auth (request cert)
>  
> >  By disrupting the authentication in whatever way (just to make it
> > fail - eg strip from field) you will then expect the peers will
> > follow new (amended) standard and retry dialback. The fact that
> > other side doesn't trust our certificate (when we know it is ok)
> > may mean there's broken integrity on this connection so we should
> > also assume the worst and drop the connection.
> 
> What? Why? If Alice finds Bob doesn't trust their certificate, but
> Alice does trust Bob's, why would Alice worry? 
Because under normal circumstances the certificate is trusted hence
expectation is it will be accepted. Same as if you know your
credentials are valid but server does not accept it. It means something
worng with the server or it is wrong server.
Let's put couple examples here - we have exchanged certificate
fingerprints with Alice - we both _must_ trust each other certificates.
If we don't there are two possibilities - misconfiguration and mitm.-
we both obtained certificates from trusted authority and expect we both
trust each other. If we don't either there's misconfiguration on our
side, on other side (CA might have revoked the cert) or the dark side
(mitm).
In other words - If Bob cares about secure communication with Alice he
cares whether she trusts his certificate or not.What is suggested
though is - let's ignore this and do our best to reach Availability,
sacrificing Integrity and Confidentiality.
> Alice's trust requirements are still met either way, and Alice can
> prove there is no MITM attack on the session to Bob.
> 
> Indeed, Alice cannot tell if Bob blindly trusts anything at all and
> always offers, and accepts, EXTERNAL. Why only be concerned about
> some kinds of misconfiguration?
> 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] NEW: XEP-0440 (SASL Channel-Binding Type Capability)

[Ruslan N. Marchenko]

Am Sonntag, den 14.06.2020, 13:05 + schrieb XEP Editor Pipeline:
> Version 0.1.0 of XEP-0440 (SASL Channel-Binding Type Capability) has
> been released.
> 
> Abstract:
> This specification allows servers to annouce their supported SASL
> channel-binding types to clients.
> 
This describes advertisement semantic however it does not solve the
main problem which channel binding mechanism is trying to solve and
which is more or less broken currently - integrity and confidentiality.

I've tried to implement that and immediatelly stumbled upon gs2_flags -
how to handle _no-match_ case? As per [5802] client needs to send y
when it thinks server does not support binding, but client does support
it.

What to do when I can bind tls-server-end-point and server can bind
tls-unique? Or opposite, whatever. If I send n, - that's a downgrade,
if I send y, - that's a clear failure case (server will abort as it
advertised -PLUS). So the only outcome is not to use SCRAM whatsoever
but that's again a downgrade.

So in a nutshell this opens a way for MitM to disable channel bindings.

Am I missing something here?

[5802] https://tools.ietf.org/html/rfc5802#section-6

--rr

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

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

[Ruslan N. Marchenko]

Am Mittwoch, den 01.07.2020, 10:37 +0100 schrieb Dave Cridland:
> On Tue, 30 Jun 2020 at 17:59, Ruslan N. Marchenko 
> wrote:
> > Am Dienstag, den 30.06.2020, 17:59 +0200 schrieb Jonas Schäfer:
> > 
> > > Hi list,
> > 
> > > 
> > 
> > > (Editor hat on)
> > 
> > > 
> > 
> > > On behalf of the Council, I’d like to bring this pull request to
> > the
> > 
> > > attention 
> > 
> > > of the community:
> > 
> > > 
> > 
> > > https://github.com/xsf/xeps/pull/963
> > 
> > > 
> > 
> > > Input from server operators specifically would be welcomed to see
> > if
> > 
> > > this 
> > 
> > > change is in fact desirable or if you can see any issues with
> > that.
> > 
> > > At least 
> > 
> > > one member of the community has already expressed [1] that they
> > think
> > 
> > > this may 
> > 
> > > lead to downgrade attacks.
> > 
> > > 
> > 
> > Let me rephrase/expand a bit my statement.
> > 
> > 
> > 
> > The SASL EXTERNAL mandates use of TLS and certificate validation
> > (XEP-
> > 
> > 0220 does not). In theory you can achieve exactly the same level of
> > 
> > security with Dialback as with EXTERNAL - eg. both sides still auth
> > 
> > each others' certificates during dialback, and similarly one can
> > put
> > 
> > additional measures such as DANE + DNSEC.
> > 
> > 
> 
> See also XEP-0344.
> 
> Note that SASL EXTERNAL absolutely does *not* mandate the use of
> either TLS or X.509 authentication - that is simply (by far) the most
> common use.
> 
In SASL (4422) no, in XMPP (6120 13.8.4 and the XEP in discussion) it
does. 

> There are two parties involved, and while EXTERNAL is nearly
> exclusively offered by the Responder when TLS is in use *and* it has
> validated the certificates of the Initiator *and* the supplied or
> inferred authorization identifier matches, it says absolutely nothing
> about the Initiator's use of TLS, X.509, etc - whether or not the
> Initiator decides to use the mechanism offered.
>  
> > Now if EXTERNAL fails - that means there's something wrong with the
> > 
> > certificates. And proposal to fail back to dialback means we want
> > to
> > 
> > tolerate certificate validation errors. Which is a downgrade.
> > 
> > 
> 
> Suggesting there is a downgrade attack here raises two important
> questions:
> 
> By whom?
> 
> Upon whom?
> 
> Let's assume that Alice.example is connecting to Bob.example. Alice
> may, or may not, have decided to trust Bob's certificate. Bob might
> have decided to trust Alice's, or might not. These are completely
> independent choices on the part of the servers.
> 
> In this scenario Bob offers EXTERNAL but then, when that is taken by
> Alice, it fails. There are few cases where this is sensible - one is
> where Alice does not provide a "from" on the stream (technically a
> violation) and the authorization identifier in EXTERNAL is either not
> present or doesn't match, one is where Alice provides a "from", but
> then uses a different authorization identifier in EXTERNAL (or at
> least one that doesn't match the certificate). Neither strike me as
> good behaviour by Alice, but still.
> 
> At this point, if Bob is willing to let Alice use Dialback (either
> pure XEP-0220, or some form of XEP-0344), why shouldn't it leave the
> session going and allow it? In other words, the downgrade "attack" is
> by Bob, on Bob.
> 
Because Alice's authentication fails on this particualr conneciton? So
it may be not Alice after all speaking, despite what 'from' tells (or
does not). From Bob's perspective someone tries to spoof Alice's server
over this connection.
> Alice, on the other hand, has already either decided to trust Bob's
> certificate or not. Nothing Bob does at this point affects that
> decision in the slightest, nor alters the security outcome of the
> decision already made. So there is no downgrade attack on Alice here.

The EXTERNAL TLS  is mutual authentication, it cannot establish
partially where one side trusts (authenticates) and other does not. By
disrupting the authentication in whatever way (just to make it fail -
eg strip from field) you will then expect the peers will follow new
(amended) standard and retry dialback. The fact that other side doesn't
trust our certificate (when we know it is ok) may mean there's broken
integrity on this connection so we should also assume the worst and
drop the connection.

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

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

[Ruslan N. Marchenko]

Am Dienstag, den 30.06.2020, 19:27 +0200 schrieb Holger Weiß:
> * Ruslan N. Marchenko  [2020-06-30 18:58]:
> > Now if EXTERNAL fails - that means there's something wrong with the
> > certificates. And proposal to fail back to dialback means we want
> > to
> > tolerate certificate validation errors. Which is a downgrade.
> 
> Whether or not this downgrade is acceptable is a policy
> decision.  The
> proposed change to XEP-0178 allows for implementing either policy
> decision in a sane way.  No?
> 
No, policy descision can be made without standard change - that's what
happenning right now. Piggybacking the standard to reflect someone's
_questionable_ policy decision is nor right thing to do. If someone
cannot configure EXTERNAL auth - let's just not advertise it, after all
it is negotiable.

--rr

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

Re: [Standards] XEP-0178: Clarify SASL-EXTERNAL specification when s2s auth fails

[Ruslan N. Marchenko]

Am Dienstag, den 30.06.2020, 17:59 +0200 schrieb Jonas Schäfer:
> Hi list,
> 
> (Editor hat on)
> 
> On behalf of the Council, I’d like to bring this pull request to the
> attention 
> of the community:
> 
> https://github.com/xsf/xeps/pull/963
> 
> Input from server operators specifically would be welcomed to see if
> this 
> change is in fact desirable or if you can see any issues with that.
> At least 
> one member of the community has already expressed [1] that they think
> this may 
> lead to downgrade attacks.
> 
Let me rephrase/expand a bit my statement.

The SASL EXTERNAL mandates use of TLS and certificate validation (XEP-
0220 does not). In theory you can achieve exactly the same level of
security with Dialback as with EXTERNAL - eg. both sides still auth
each others' certificates during dialback, and similarly one can put
additional measures such as DANE + DNSEC.

Now if EXTERNAL fails - that means there's something wrong with the
certificates. And proposal to fail back to dialback means we want to
tolerate certificate validation errors. Which is a downgrade.

Now, if we want to loosen the failure scenario, we need to explicitly
call out that this is only acceptable without loss of security controls
(validation) - eg just a misconfiguration. 

Now again EXTERNAL misconfiguration is kind of obvious - connection is
lost if integrity/confidentiality is not achievable. Dialback does not
put anything like that in place to ensure that.

Regards,
Ruslan

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

Re: [Standards] XMPP Council Agenda 2020-06-24

[Ruslan N. Marchenko]

Am Dienstag, den 23.06.2020, 18:55 +0200 schrieb Jonas Schäfer:
> Hi everyone,
> 
...
> 4a) PR#963: PR#963: XEP-0178: Clarify SASL-EXTERNAL specification
> when s2s 
> auth fails
> URL: https://github.com/xsf/xeps/pull/963
> Abstract: A while back it was discussed that XEP-0178 (SASL-EXTERNAL) 
> for s2s 
> was kinda misleading - it says that server should close connection
> if 
> authentication fails but it seems that "everyone" (at least
> Prosody[0] and 
> ejabberd) actually fallbacks to dialback in that case.
> 
Isn't it a classic downgrade attack? Reflecting status quo is not
always the best thing to do.

>[0]: https://issues.prosody.im/1006
> 
> 

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

Re: [Standards] Proposed XMPP Extension: Quick Response

[Ruslan N. Marchenko]

Am Dienstag, den 21.04.2020, 10:44 + schrieb p...@bouah.net:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: Quick Response
> Abstract:
> Quickly respond to automated messages.
> 
I like the quick response thingy, reminds me of canned messages on
pebble. So could be used on smart devices with limited input/attention
like car-kits, smartwatches, home automation (clap clap clap).

URL: https://xmpp.org/extensions/inbox/quick-response.html
> 
> The Council will decide in the next two weeks whether to accept this
> proposal as an official XEP.
> ___
> 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] LAST CALL: XEP-0357 (Push Notifications)

[Ruslan N. Marchenko]

Am Dienstag, den 31.03.2020, 20:38 + schrieb Jonas Schäfer:
> This message constitutes notice of a Last Call for comments on
> XEP-0357.
> 
> Title: Push Notifications
> Abstract:
> This specification defines a way for an XMPP servers to deliver
> information for use in push notifications to mobile and other
> devices.
> 
> URL: https://xmpp.org/extensions/xep-0357.html
> 
> This Last Call begins today and shall end at the close of business on
> 2020-04-08.
> 
> 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?
> 
No

> 2. Does the specification solve the problem stated in the
> introduction
> and requirements?
> 
Kind of

> 3. Do you plan to implement this specification in your code? If not,
> why not?
> 
Yes, implemented server-side but not sure whether it was worth it

> 4. Do you have any security concerns related to this specification?
> 
Not in the current state

> 5. Is the specification accurate and clearly written?
> 
Not quite, too many dependencies on the push vendor/implementation
specifics so was forced to read the code (Daniel's p2) to understand
what is expected on the other side.

> Your feedback is appreciated!
> ___
> 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] XEP-0313: pending 0.7 update review

[Ruslan N. Marchenko]

Am Samstag, den 04.04.2020, 11:47 +0200 schrieb Philipp Hörist:
> Hi,
> 
> Am Sa., 4. Apr. 2020 um 11:33 Uhr schrieb Ruslan N. Marchenko <
> m...@ruff.mobi>:
> > Thanks, that makes perfect sense to me as in my limited _mere p2p
> > conversation_ use case all those bells and whistles are rather
> > confusing.I don't understand though the need of _flip-page_ element
> > - the reverse _page_ order is achieved by  element (as
> > specified here [1]). Is it to reverse _message_ order
> > (contradicting to section Querying an archive)?
> > 
> 
>  gives you the last page in chronological order, there comes
> no use case to mind where this is useful.
> 
> - Either i want to sync up, then i want them in chronological order,
> so i dont use 
> - Or i want to "backscroll" through history, then i want them in
> reversed order which  and  now make possible

To me this doesn't make much difference, last page in proper or reverse
order will still require manual re-ordering in the GUI which already
displays some messages. Same for scrolling back (and re-syncing
archive).
It does make sense when using large pages on a fresh (or thin) client -
then yes, you simply prepend messages as they go without much concern.
Is it a convenience method just for this use case?

>  
> > * Communicating the archive ID: not sure how to formulate it but
> > something along the lines: if client expects message
> > synchronisation for outgoing messages it MUST add origin-ID to the
> > sent message and store the ID locally for future synchronisation.*
> > Business Rules -> Storage and Retrieval Rules -> User Archives : At
> > a minimum, the server MUST store the body elements of a
> > stanza. The server also MUST store origin-id element if that was
> > supplied in outgoing message by archive owner.
> > 
> 
> Its not strictly needed that the archive preserves the origin-id, its
> not even needed for deduplication that you use origin-id at all.
> Whatever you put now in origin-id, just put into the standard
> message-id attribute. message-id attribute is already preserved by
> servers.

Oh, i didn't know that (and didn't implement that of course server-
side). This will do, although again spec needs to explicitly mention
that. To me message id was always client side tracking (receipts and
stuff) which server has nothing to do about.
My point is rather - specification should call out the need for
outgoing message synchronisation and recommend a mechanism for that
which both client and server implementers can rely on.

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

Re: [Standards] XEP-0313: pending 0.7 update review

[Ruslan N. Marchenko]

Am Freitag, den 03.04.2020, 21:51 +0100 schrieb Matthew Wild:
> Hi folks,
> 
> XEP-0313 is a well-established protocol at this point, but didn't yet
> make it to the next stage in the standards process. Time to fix that!
> 
> I have made a final round of updates to incorporate the various
> feedback I have received from people who have implemented the
> protocol over the past couple of years.
> 
> One thing that kept coming up was splitting out some non-
> essential/rougher parts of the document. This I have done:
> preferences and pubsub archives have been split off to be separate
> XEPs.
> 
> Preferences are not widely implemented, and actually implementing and
> using them has the potential to mess up the way many clients use MAM
> for sync today - these days I don't think it's a feature that should
> generally be exposed to users without caution.
> 
> Pubsub archives are something that is conceptually simple, but that I
> think people still have a fair few questions about. So splitting that
> into a new document will hopefully give it some room to grow.
> 
> The core of XEP-0313 that remains has actually gained some new
> features that were repeatedly requested by people to help with
> implementation issues. Importantly the namespace has not been bumped,
> but servers that support the new update will indicate this with an
> extra disco feature.
> 
> The PRs are here:
> 
> XEP-0313: https://github.com/xsf/xeps/pull/922
> MAM Preferences: https://github.com/xsf/xeps/pull/920
> Pubsub MAM: https://github.com/xsf/xeps/pull/921
> 
> Feedback very welcome, but I hope we can get this wrapped up and
> advanced to Draft where it should be soon!
> 
Thanks, that makes perfect sense to me as in my limited _mere p2p
conversation_ use case all those bells and whistles are rather
confusing.I don't understand though the need of _flip-page_ element -
the reverse _page_ order is achieved by  element (as specified
here [1]). Is it to reverse _message_ order (contradicting to
section Querying an archive)?
Anyway what I would like to see though is some more love to
synchronisation issue - it is explicitly written that real-time-sync is
out of scope but there's a gap which may lead to more mess in the
future.
The xep mandates archiving entity to attach stanza-id for forward ID
notification, however reverse ID mapping creates a gap in the
specification. While implementing this on the server side I've followed
minimal requirements (only body must be stored) and it worked kind of
ok (there are some occasional dups but mostly in ingress
direction).While implementing this on the client side I've realized I
have no way to resolve message duplication issue following just minimal
specification. So I was forced to look at how other people resolved
this issue to avoid creating YAMTRD (yet another method to resolve
duplicaiton).So why not capture in the specification existing practice
to resolve this - namely* mandate storage of origin-id (and its support
by the client) and * client usage of the oid-to-sid mapping while
retrieving the archiveI understand it would be too much perhaps to
require the *client* to store oid for future use in deduplication but
if the spec mandates server to preserve oid and hints that it to use
for sync - that should  allow client to rely on the fact the oid will
always be there to help.To recap:* Communicating the archive ID: not
sure how to formulate it but something along the lines: if client
expects message synchronisation for outgoing messages it MUST add
origin-ID to the sent message and store the ID locally for future
synchronisation.* Business Rules -> Storage and Retrieval Rules -> User
Archives : At a minimum, the server MUST store the body
elements of a stanza. The server also MUST store origin-id element if
that was supplied in outgoing message by archive owner.
[1] - https://xmpp.org/extensions/xep-0059.html#backwards
--rr

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

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

[Ruslan N. Marchenko]

On Thu, Sep 05, 2019 at 12:58:53PM +0200, Philipp Hörist wrote:
> Am Do., 5. Sept. 2019 um 12:36 Uhr schrieb Ruslan N. Marchenko 
> :
> 
> 
> > And in 0353 messages are body-less hence not
> eligible for carbons.
> 
> 
> 
> bodyless is eligible for carbons if the message is of type "chat". We use this
> on many XEPs, receipts, all encrypted messages, markers, chatstates etc 

So the only change to XEP required to make it carbons-compatible is to
switch to explicit type='chat' from implicit 'normal'.

--RR

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

Re: [Standards] LAST CALL: XEP-0353 (Jingle Message Initiation)

[Ruslan N. Marchenko]

On Thu, Sep 05, 2019 at 12:42:23PM +0500, Andrew Nenakhov wrote:
> вт, 3 сент. 2019 г. в 23:18, Georg Lukas :
> >
> > Speaking of 0353 as is, it was also not designed for Carbons. I think we
> > should explicitly make use of Carbons (by similar means as with MAM), so
> > that we do not need separate  (to self) and  (to the
> > initator) messages. Instead, the  will be carbon-copied to all
> > other resources, letting them know that one client accepted the call.
> 
> Why is 353 not designed for carbons?  is a  and
> should be sent to other connected resources once the call is accepted.
> I'd say that current XEP-0353 specification is designed exclusively
> for carbons.
> 
Because of urn:xmpp:carbons:rules:0 perhaps? Anyone can implement
whatever rules on the server, however the only thing client can rely on
is 6.1 of the XEP-0280. And in 0353 messages are body-less hence not
eligible for carbons. 

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

Re: [Standards] XEP-0288 - Bidi - Maybe CFE?

[Ruslan N. Marchenko]

Am Dienstag, den 03.09.2019, 10:58 + schrieb Maxime “pep” Buquet:
> On September 3, 2019 10:55:18 AM UTC, Dave Cridland <
> d...@cridland.net> wrote:
> > Thanks for your snappy response.
> > 
> > On Mon, 2 Sep 2019 at 18:13, Ruslan Marchenko  wrote:
> > 
> > > Hi,
> > > 
> > > I've recently realized my bidi implementation lacks SASL External
> > > outbound support - but when trying to implement it I figured my
> > > bidi
> > > external test now fails because the target I used earlier for
> > > BIDI
> > > end2end test (metronome.im) now dropped its support. So now
> > > wonder
> > > whether there's any known issue with this so that no one supports
> > > it in
> > > the wild? I have always thought this is the future state of s2s
> > > and
> > > sooner or later everyone would move to it but it looks quite
> > opposite.
> 
> Not sure where you got this impression. There's actually quite a few
> servers lately with bidi support since it's been marked as "stable"
> in prosody modules. Somebody had stats on prosody@ iirc.
> 
Maybe after seeing this features from prosody.im

and from many others I've tried. But I'm happpy to be wrong here and be
seeing growing implementation base.

Regards,
Ruslan

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

Re: [Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing

[Ruslan N. Marchenko]

Am Dienstag, den 27.02.2018, 15:37 -0700 schrieb Peter Saint-Andre:
> On 2/27/18 10:33 AM, Ruslan N. Marchenko wrote:
> > That actually touches a point which is nagging me each time I'm
> > looking
> > into implementation. Who is responsible for closing the session? 
> > 
> > According to this [1] it is recommended that receiving party closes
> > the
> > session as soon as it receives complete file. 
> > But that doesn't leave the space for adding files into the session,
> > as
> > it relies on concurrency - eg whether receiving party receives (or
> > actually processes) complete transfer sooner than 'content-add'
> > stanza.
> > 
> > [1] https://xmpp.org/extensions/xep-0234.html#sect-idm1399045441849
> > 76
> 
> Actually, that says "Once all file content in the session has been
> transfered, either party MAY acknowledge receipt of the received
> files";
Yes, it may, but recommendation is
"Preferably, sending the session-terminate is done by the last entity
to finish receiving a file to ensure that all offered or requested
files by either party have been completely received (up to the
advertised sizes)."
> note that "all file content" might include multiple files if XEP-0358
> (Publishing Available Jingle Sessions) is used.
> 
Which receiving party has no ability to know in advance.
> So unfortunately I think the answer is: "it depends".
> 
Right, so that's the point of the question. I think it should be
clearly specified. Otherwise there might be session leaking.
Basically this session leaking (initiator does not close it) forced me
to follow recommendation and send session-terminate on transfer
complete.
In current definition ack is voluntary, which means in absence of ack
initiator has no idea when transfer is complete by the target and it is
safe to close the session.
So let say - either party MAY close the session but it is recommended
(or even required) that the initiator to be responsible for closing it
to ensure proper session cleanup - after receiving confirmation as
described below.

> If there is a single file involved, then the receiver can terminate
> the
> session after it has received that single file.
> 
> But, what if the sender has advertised only a single file (in the
> Jingle
> session-initiate message) yet has more to send? In that case, the
> ideal
> flow would be:
> 
> (1) the receiver acknowledges receipt by sending a 
> message
> as in §8.1
> 
> (2) the initiator sends a Jingle content-add action as in §6.3
> 
> (3) the receiver acks the content-add request
> 
> (4) the initiator sends the next file
> 
> After the receiver acknowledges receipt of the last file in the
> session,
> the initiator would terminate the session.
> 
precisely. but that's almost a new protocol, would need a bump to
ensure implementation follows new guidelines/semantic.

> That is the "push" scenario. In the "pull" scenario (XEP-0358), it
> seems
> best for the receiver to terminate the session.
> 
I didn't yet digest pull scenario so cannot comment, but the idea is
that the party which knows exactly what is to be sent (active or
passive initiator so to say) is to be responsible for closure.
Counterparty may implement idle-timeouts to avoid abandoned
sessions (crashed subsystem) leakage.


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

Re: [Standards] [XEP-0234] Jingle File Transfer, Last Call and File Sharing

[Ruslan N. Marchenko]

Am Montag, den 26.02.2018, 19:21 -0700 schrieb Peter Saint-Andre:
> 
> The idea there was to allow multiple files to be sent in a session;
> you
> wouldn't close the session if you want to send more files, so you
> would
> send the  element defined in §8.1 instead. IMHO a good
> solution would be to always ("MUST") send  upon receipt of
> the complete file, and to always ("MUST") terminate the session with
>  after sending the last file. Yes, this means you'd send
> both
>  and  in a one-file session, but that doesn't
> seem
> horrible and at least all the state transitions are explicitly
> defined.
> 
> 

That actually touches a point which is nagging me each time I'm looking
into implementation. Who is responsible for closing the session? 

According to this [1] it is recommended that receiving party closes the
session as soon as it receives complete file. 
But that doesn't leave the space for adding files into the session, as
it relies on concurrency - eg whether receiving party receives (or
actually processes) complete transfer sooner than 'content-add' stanza.

[1] https://xmpp.org/extensions/xep-0234.html#sect-idm139904544184976
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0198: Stream should be closed when 'h' value is to high

[Ruslan N. Marchenko]

Am Mittwoch, den 21.02.2018, 16:17 + schrieb Kevin Smith:
> On 21 Feb 2018, at 13:21, Jonas Wielicki  wrote:
> > 
> > On Mittwoch, 21. Februar 2018 11:57:56 CET Kevin Smith wrote:
> > > On 21 Feb 2018, at 09:41, Jonas Wielicki 
> > > wrote:
> > > > On Mittwoch, 21. Februar 2018 10:32:37 CET Kevin Smith wrote:
> > > > > At first glance, its seems to me like this can only happen
> > > > > when an
> > > > > entity’s
> > > > > 198 support is broken in some way. If that’s the case, would
> > > > > we expect
> > > > > the
> > > > > same entity to reconnect and do the same thing again? If so,
> > > > > is it better
> > > > > to continually disconnect due to bad-h, reconnect, etc., or
> > > > > to do the
> > > > > best
> > > > > we can to keep the stream up?
> > > > 
> > > > The entity shouldn’t be reconnecting after a stream error, so
> > > > the loop
> > > > you’re talking about won’t happen (unless the entity is also
> > > > broken in
> > > > other ways, but one can construct arbitrary failure modes if we
> > > > assume
> > > > that).
> > > 
> > > I don’t think this is true.
> > 
> > I meant to say resumption instead of reconnection, sorry.
> > 
> > For resumption this is true I think. A stream which died with a
> > stream error 
> > is properly closed (), thus all stream management
> > state is 
> > discarded on both sides.
> 
> For resumption it’s true, but reconnection was what I was talking
> about.
> 
> 

Why would you adopt the *protocol* to the broken *implementation* in
the first place?
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Jingle (File Transfer) Session termination

[Ruslan N. Marchenko]

On 28.12.2017 22:41, Ruslan N. Marchenko wrote:


On 28.12.2017 20:41, Lance Stout wrote:
Both sides locally terminated the session, so both sides should be in 
the ENDED

state. Period. Full stop.
That is a perfectly legal sequence of actions to take, but this 
particular
combination suggests that the Jingle library could be improved here. 
The spec
mandates that the _receiving_ side of a content-reject or 
content-remove send
a session-terminate if there are no remaining contents. The, 
unfortunately
unwritten, implication is that the _sending_ side should just go 
ahead and send a
session-terminate if it is going to reject or remove the last 
content. This whole

scenario would have been avoided if Telepathy behaved that way.
Yes, that was my initial thought to check disposition=session and 
is-last-content condition and abort entire session. Just tried to 
minimize interaction with jingle library and not to oversee session 
state from content perspective. Will also require Wocky patching.

Seems even decline is not helping here

<<<
(telepathy-gabble:1771): wocky-DEBUG: _end_element_ns: Received stanza
* iq xmlns='jabber:client' nsp0='jabber:server' 
id='dd6643d4-58d5-428f-8602-8d8bec1122d8' type='set' lang='de' 
to='m...@ruff.mobi/Emush' from='r...@xmpp.zone/gajim.R8P5E74S'
    * jingle xmlns='urn:xmpp:jingle:1' action='session-initiate' 
sid='5e641eb5-a93e-4f4c-91a5-8d35ec344d54' 
initiator='r...@xmpp.zone/gajim.R8P5E74S'

    * content name='fileIYV4MRTJW2FDPCX0' creator='initiator'
    * description xmlns='urn:xmpp:jingle:apps:file-transfer:3'
    * offer
    * file
    * name
    "lpcx"
    * date
    "2015-01-24T22:37:13"
    * size
    "267"
    * desc
    * transport xmlns='urn:xmpp:jingle:transports:ibb:1' 
block-size='4096' sid='3469de9b-3c09-478b-8194-5f7bca189de7'


>>>
(telepathy-gabble:1771): wocky-DEBUG: _write_node_tree: Serializing tree:
* iq xmlns='jabber:client' type='set' to='r...@xmpp.zone/gajim.R8P5E74S' 
id='3307134724'
    * jingle xmlns='urn:xmpp:jingle:1' 
initiator='r...@xmpp.zone/gajim.R8P5E74S' 
sid='5e641eb5-a93e-4f4c-91a5-8d35ec344d54' action='session-info'

    * ringing xmlns='urn:xmpp:jingle:apps:rtp:info:1'
>>>
(telepathy-gabble:1771): wocky-DEBUG: _write_node_tree: Serializing tree:
* iq xmlns='jabber:client' type='result' from='m...@ruff.mobi/Emush' 
to='r...@xmpp.zone/gajim.R8P5E74S' id='dd6643d4-58d5-428f-8602-8d8bec1122d8'


>>>
(telepathy-gabble:1771): wocky-DEBUG: _write_node_tree: Serializing tree:
* iq xmlns='jabber:client' type='set' to='r...@xmpp.zone/gajim.R8P5E74S' 
id='4101041570'
    * jingle xmlns='urn:xmpp:jingle:1' 
initiator='r...@xmpp.zone/gajim.R8P5E74S' 
sid='5e641eb5-a93e-4f4c-91a5-8d35ec344d54' action='session-terminate'

    * reason
    * decline
<<<
(telepathy-gabble:1771): wocky-DEBUG: _end_element_ns: Received stanza
* iq xmlns='jabber:client' id='3307134724' nsp0='jabber:server' 
type='result' lang='de' to='m...@ruff.mobi/Emush' 
from='r...@xmpp.zone/gajim.R8P5E74S'

<<<
(telepathy-gabble:1771): wocky-DEBUG: _end_element_ns: Received stanza
* iq xmlns='jabber:client' lang='de' type='result' nsp0='jabber:server' 
id='4101041570' to='m...@ruff.mobi/Emush' from='r...@xmpp.zone/gajim.R8P5E74S'


and in GUI transfer is still hanging *sigh*.
However when client is registering channel handler for file-transfer 
channel the transfer is ok and completes successfully.


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

Re: [Standards] Jingle (File Transfer) Session termination

[Ruslan N. Marchenko]

On 28.12.2017 20:41, Lance Stout wrote:

Both sides locally terminated the session, so both sides should be in the ENDED
state. Period. Full stop.

The fact that one side ended up getting an error response to their
session-terminate is irrelevant, because (as you quoted) when locally
terminating the session, the session state moves to ENDED without regard to any
ack from the other side, whether that be a success, error, or no response at
all.

So the session still showing as hanging in the Gajim UI is a client/library bug.
It seems to be waiting for a successful IQ-result before fully cleaning up and
treating the session as ended.



That said, here's a summary of the traffic logs you sent:

   |ruff (gajim)  me (tp)

  1| session-initiate -->
  2|  <--session-info
  3|  <--iq-result(1)
  4|  <--  content-reject
  5| iq-result(2) -->
  6| iq-result(4) -->
  7|  <--   session-terminate
  8| session-terminate-->
  9|  <-- iq-error(8)
10| iq-result(7) -->


Again, none of this changes the conclusion from above, but looking through this
could be helpful anyway.

Ok, thanks for a feedback, it matches my understanding as well.


The telepathy side is sending a session-info for RTP ringing before even sending
iq-result(1) acknowledging the session-initiate. That's not particularly
harmful here, but it 1) really shouldn't be there at all since there are no RTP
applications involved in the session and 2) should at least have been sent after
iq-result(1). It suggests that Telepathy is probably not queueing local actions,
which could lead to state bugs.
That's imprinted in Wocky Jingle implementation and I so far am messing 
with Gabble implementation. So yes, that Ringing message could be 
removed/suppressed/reordered or moved to RTP content handler. Currently 
it's unconditionally fired if content namespace has a consumer - eg. 
once content is parsed and content object is successfully allocated. 
Ack(result) then follows if entire IQ processing hasn't triggered any 
error. I believe TP does this as an early pre-ack expecting that full 
session-initiate processing may take some time to call out all codecs 
and transports (after which only it can send full proper ack/result). 
Perhaps these two should be swapped but hat would require moving entire 
content processing into callback (note to self).
However XEP-0166 6.8 is explicitly calling out that these messages are 
harmless (as you noted above) and should be treated as pings unless 
fully understood.


As you stated, the telepathy side doesn't understand the offered file-transfer
application. Telepathy has the correct interpretation here that it should reject
that particular content. To do so, it is sending a content-reject action, which
is perfectly legal. And immediately after doing so, it notices that there are no
remaining contents, and so sends a session-terminate.
Well it does understand offered file-transfer (in my PoC version), it 
just does not have any client interested in handling this ChannelType 
(org.freedesktop.Telepathy.Channel.Type.FileTransfer).
So yes, ChannelDispatcher just closes the offered channel on sight 
because no client registered a handler for this type (only 
org.freedesktop.Telepathy.Channel.Type.Text) thus no one can accept. And 
that causes a rejection.
I'll need to make some stub auto-accepting client/handler to proceed 
with actual transfer, so far just polishing JingleFT implementation 
(parser/state-machine/transports/hookups/etc.).


That is a perfectly legal sequence of actions to take, but this particular
combination suggests that the Jingle library could be improved here. The spec
mandates that the _receiving_ side of a content-reject or content-remove send
a session-terminate if there are no remaining contents. The, unfortunately
unwritten, implication is that the _sending_ side should just go ahead and send 
a
session-terminate if it is going to reject or remove the last content. This 
whole
scenario would have been avoided if Telepathy behaved that way.
Yes, that was my initial thought to check disposition=session and 
is-last-content condition and abort entire session. Just tried to 
minimize interaction with jingle library and not to oversee session 
state from content perspective. Will also require Wocky patching.


The Gajim side of the session after receiving the content-reject dutifully
follows the spec and terminates the session because there are no remaining
contents.

We are left in what would otherwise be a tie-breaking situation. Notice
that both sides send a session-terminate before receiving the respective
iq-result/iq-error replies, which means both sides attempted to change the
session in the same ways without being aware of the other also trying to do
so. The tie-breaking 

Re: [Standards] Jingle (File Transfer) Session termination

[Ruslan N. Marchenko]

On 29.11.2017 20:25, Ruslan N. Marchenko wrote:


On 29.11.2017 17:42, Jonas Wielicki wrote:


Daniel thinks that there are clients which can only do SI, but 
doesn’t recall

any off the top of his head.
Telepathy-gabble for one supports only SI. I'm currently looking if i 
can monkeypatch existing ft-manager to handle jingle but this is in 
early PoC phase as of yet.


I'm lazily progressing in this PoC and stumbled upon certain 
questionable behaviour. Before claiming it as a (gajim) bug I want some 
comments.


So we have a jingle session which is declined (no handler for this 
channel type registered hence auto-declined) by Telepathy.
However gajim (which I use as a reference implementation for the test) 
not accepting the decline and lists transfer as hanging till 
'unavailable' presence.


Session transcript:

Incoming session from gajim:
(telepathy-gabble:3286): wocky-DEBUG: _end_element_ns: Received stanza
* iq xmlns='jabber:client' type='set' lang='de' nsp0='jabber:server' 
id='d315b7de-c823-4c97-a636-17fd0d5f8692' to='m...@ruff.mobi/Emush' 
from='r...@xmpp.zone/gajim.UECVS9Q6'
    * jingle xmlns='urn:xmpp:jingle:1' 
initiator='r...@xmpp.zone/gajim.UECVS9Q6' 
sid='4ce275a0-f858-4607-8272-418430f14bb1' action='session-initiate'

    * content name='fileLREV64SKBODW8GAP' creator='initiator'
    * description xmlns='urn:xmpp:jingle:apps:file-transfer:3'
    * offer
    * file
    * name
    "lpcx"
    * date
    "2015-01-24T22:37:13"
    * size
    "267"
    * desc
    * transport xmlns='urn:xmpp:jingle:transports:ibb:1' 
block-size='4096' sid='9c9e19a0-a383-46c1-8fd1-f1d5407437bc'


Intermediate TP ack (TP stack implementation, could be ignored)
(telepathy-gabble:3286): wocky-DEBUG: _write_node_tree: Serializing tree:
* iq xmlns='jabber:client' type='set' to='r...@xmpp.zone/gajim.UECVS9Q6' 
id='49488115057'
    * jingle xmlns='urn:xmpp:jingle:1' 
initiator='r...@xmpp.zone/gajim.UECVS9Q6' 
sid='4ce275a0-f858-4607-8272-418430f14bb1' action='session-info'

    * ringing xmlns='urn:xmpp:jingle:apps:rtp:info:1'

TP IQ ACK
(telepathy-gabble:3286): wocky-DEBUG: _write_node_tree: Serializing tree:
* iq xmlns='jabber:client' type='result' from='m...@ruff.mobi/Emush' 
to='r...@xmpp.zone/gajim.UECVS9Q6' id='d315b7de-c823-4c97-a636-17fd0d5f8692'


TP Jingle Content NACK - this is questionable, again generated by stack 
but is not violation (unused by FT:3 XEP)

(telepathy-gabble:3286): wocky-DEBUG: _write_node_tree: Serializing tree:
* iq xmlns='jabber:client' type='set' to='r...@xmpp.zone/gajim.UECVS9Q6' 
id='55569122241'
    * jingle xmlns='urn:xmpp:jingle:1' 
initiator='r...@xmpp.zone/gajim.UECVS9Q6' 
sid='4ce275a0-f858-4607-8272-418430f14bb1' action='content-reject'

    * reason
    * decline
    * content name='fileLREV64SKBODW8GAP' senders='initiator' 
creator='initiator'


Gajim Jingle ringing IQ ACK
(telepathy-gabble:3286): wocky-DEBUG: _end_element_ns: Received stanza
* iq xmlns='jabber:client' type='result' lang='de' id='49488115057' 
nsp0='jabber:server' to='m...@ruff.mobi/Emush' 
from='r...@xmpp.zone/gajim.UECVS9Q6'


Gajim Jingle content-nack IQ ACK
(telepathy-gabble:3286): wocky-DEBUG: _end_element_ns: Received stanza
* iq xmlns='jabber:client' nsp0='jabber:server' id='55569122241' 
type='result' lang='de' to='m...@ruff.mobi/Emush' 
from='r...@xmpp.zone/gajim.UECVS9Q6'


TP Jingle Session NACK
(telepathy-gabble:3286): wocky-DEBUG: _write_node_tree: Serializing tree:
* iq xmlns='jabber:client' type='set' to='r...@xmpp.zone/gajim.UECVS9Q6' 
id='283410939952'
    * jingle xmlns='urn:xmpp:jingle:1' 
initiator='r...@xmpp.zone/gajim.UECVS9Q6' 
sid='4ce275a0-f858-4607-8272-418430f14bb1' action='session-terminate'

    * reason
    * cancel

Now this is where I think it's getting stuck. TP deallocates Jingle 
session by this time, only leaving IQ ACK handler.

So when it gets following:
(telepathy-gabble:3286): wocky-DEBUG: _end_element_ns: Received stanza
* iq xmlns='jabber:client' type='set' lang='de' 
id='8fbd3391-2f2d-4ccb-af1f-4b363fdc7581' nsp0='jabber:server' 
to='m...@ruff.mobi/Emush' from='r...@xmpp.zone/gajim.UECVS9Q6'
    * jingle xmlns='urn:xmpp:jingle:1' 
initiator='r...@xmpp.zone/gajim.UECVS9Q6' 
sid='4ce275a0-f858-4607-8272-418430f14bb1' action='session-terminate'

    * reason
    * success
it replies with
(telepathy-gabble:3286): wocky-DEBUG: _write_node_tree: Serializing tree:
* iq xmlns='jabber:client' type='error' from='m...@ruff.mobi/Emush' 
to='r...@xmpp.zone/gajim.UECVS9Q6' id='8fbd3391-2f2d-4ccb-af1f-4b363fdc7581'
    * jingle xmlns='urn:xmpp:jingle:1' 
initiator='r...@xmpp.zone/gajim.UECVS9Q6' 
sid='4ce275a0-f858-4607-8272-418430f14bb1' action='session-terminate'

    * reason
    * success
    *

Re: [Standards] LAST CALL: XEP-0363 (HTTP File Upload)

[Ruslan N. Marchenko]

On 29.11.2017 20:16, Jonas Wielicki (XSF Editor) wrote:

This message constitutes notice of a Last Call for comments on
XEP-0363.

Title: HTTP File Upload
Abstract:
This specification defines a protocol to request permissions from
another entity to upload a file to a specific path on an HTTP server
and at the same time receive a URL from which that file can later be
downloaded again.

URL: https://xmpp.org/extensions/xep-0363.html

This Last Call begins today and shall end at the close of business on
2017-12-12.

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?

I'm not quite sure about it. Alas it works.

2. Does the specification solve the problem stated in the introduction
and requirements?

That it does.

3. Do you plan to implement this specification in your code? If not,
why not?

Yes, because it works already.

4. Do you have any security concerns related to this specification?
Yes, I don't like the approach with wide open PUT limited by certain 
high-level content constraints and (luckily) headers in the latest revision.
At least content hash (as in jingle) would be beneficial. Shall we say 
slot path element (public one) should be content hash (and hence part of 
request)?
That allows all 3 parties (sender, mediator, receiver) to verify somehow 
validity of the content. Otherwise there's possibility of the content 
injection.

5. Is the specification accurate and clearly written?


XMPP part yes. The rest is left to implementers.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

[Ruslan N. Marchenko]

On 07.12.2017 18:35, Jonas Wielicki (XSF Editor) wrote:

This message constitutes notice of a Last Call for comments on
XEP-0352.

Title: Client State Indication
Abstract:
This document defines a way for the client to indicate its
active/inactive state.

URL: https://xmpp.org/extensions/xep-0352.html

This Last Call begins today and shall end at the close of business on
2017-12-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?


Yes.


2. Does the specification solve the problem stated in the introduction
and requirements?

Yes.


3. Do you plan to implement this specification in your code? If not,
why not?

Yes.


4. Do you have any security concerns related to this specification?

No.


5. Is the specification accurate and clearly written?

It is intentionally leaves lot of space for implementers, but we can 
live with it for the time being.
Presence and bodiless stanzas are called out and they represent majority 
of the messages which could be safely dropped/delayed (yes, there's also 
omemo).


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

Re: [Standards] UPDATED: XEP-0363 (HTTP File Upload)

[Ruslan N. Marchenko]

On 05.12.2017 10:39, Evgeny Khramtsov wrote:

Tue, 5 Dec 2017 08:30:38 +
Kevin Smith  wrote:


2) New namespace: previous version payloads are allowed through, new
versions won’t be allowed through until the validator is updated

No, new namespaces are treated as unknown and are routed untouched.
ugh
But XML Schema for 0363 is _TBD_ yet, which means it should be in 
_untouched_ mode. in this particular case at least.
I think validation could make sense for XEPs starting from Draft - eg 
something eno stabilized. Validating experimental... is questionable 
gain. For sure for developers, doubtfully for end users.

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

Re: [Standards] 2017-11-29 XMPP Council Meeting Minutes

[Ruslan N. Marchenko]

On 29.11.2017 17:42, Jonas Wielicki wrote:

Present: Dave (Chair), Kevin, Georg, Daniel, Sam
Minutes: Yours truly.

Chat logs: http://logs.xmpp.org/council/2017-11-29#15:55:08

...

2. Vote on deprecating XEP-0095 (Stream Initiation)
---

Sam did research on this one. It appears of the clients he inspected, not any
client *only* supported Stream Initiation (they all supported either
[XEP-0234] (Jingle File Transfer), Jingle *and* SI, or neither). (see the
Trello card [1] for details)ft-manager tp

Daniel thinks that there are clients which can only do SI, but doesn’t recall
any off the top of his head.
Telepathy-gabble for one supports only SI. I'm currently looking if i 
can monkeypatch existing ft-manager to handle jingle but this is in 
early PoC phase as of yet.
(telepathy-gabble:1776): gabble-DEBUG: emit_capabilities_update 
(presence-cache.c:1125): Emitting caps update for handle 1

  --added--
  Feature: http://www.google.com/xmpp/protocol/session
  Feature: urn:xmpp:jingle:transports:raw-udp:1
  Feature: http://jabber.org/protocol/jingle
  Feature: http://jabber.org/protocol/nick
  Feature: http://jabber.org/protocol/si
  Feature: http://jabber.org/protocol/ibb
  Feature: http://telepathy.freedesktop.org/xmpp/tubes
  Feature: http://jabber.org/protocol/bytestreams
  Feature: jabber:iq:last
  Feature: http://jabber.org/protocol/jingle/description/audio
  Feature: urn:xmpp:jingle:apps:rtp:1
  Feature: urn:xmpp:jingle:apps:rtp:audio
  Feature: urn:xmpp:jingle:apps:rtp:rtp-hdrext:0
  Feature: urn:xmpp:jingle:apps:rtp:rtcp-fb:0
  --end--


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

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

[Ruslan N. Marchenko]

On 18.11.2017 17:14, Philipp Hörist wrote:
Why would a server allow that if it has no use case and leads to 
problems?


When a client sets the preferences the server replies with the full 
pref list, this gives the server the possibility to refuse some entries.


The XEP also states

note that due to server policies these MAY be different to the 
preferences sent by the client



we could blow this whole pref thing up with defining errors for all 
kind of things that may happen, but as it was suggested already, prefs 
should be excluded from the xep and put into its own xep.


That's fine, however XEP still should specify default archiving rules, 
at least _recommended_. Like - store everything, store nothing, store by 
roster, etc.
Since MAM is not negotiable there's no option for user to opt-out except 
prefs. So I'd be strongly against default store-everything.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

[Ruslan N. Marchenko]

On 05.11.2017 19:21, Ruslan N. Marchenko wrote:

Hi,


On 16.10.2017 20:38, Jonas Wielicki (XSF Editor) wrote:

5. Is the specification accurate and clearly written?
The first thing I stumbled upon while starting drafting implementation 
is - empty result.

?
?
0?
Or perhaps even ?


Some more questions:
2.
XEP states at 6.1.1
> 'roster' - messages are archived only if the contact's bare JID is in 
the user's roster.
shouldn't it say instead - if contact's bare JID is in the user's roster 
with 'from' or 'both' subscription.
Or perhaps - for incoming messages should be at least 'to' and for 
outgoing - 'from'?


3.
Should we consider full run against both always and never to find 
most-specific match or we just do first-hit and ignore the rest?
The former sounds more plausible to me as it allows fine-tuning with 
blocking a specific resource or in opposite - archive only a specific 
resource.

On the other hand later is more simplistic for implementation.

4.
Then - what is the order of comparison? I.e. if (for some unknown 
reason) jid is present in both always and never lists with identical 
precision?



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

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

[Ruslan N. Marchenko]

On 14.11.2017 22:37, Sam Whited wrote:


What do the server devs here think?


To be fair this protocol is implemented in majority(?) of existing xmpp 
server implementations so the burden is zero.
The question is rather - what is the future vision for this component 
protocol? It considered as a necessary communication method for new 
external services or s2s with all the new features (like bidi) is 
sufficient making this one redundant. My personal answer is - go S2S. 
But at the same time i'm not doing much of component development 
therefore cannot say whether XEP-0114 is really resolving some corner 
cases hence being irreplaceable.


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

Re: [Standards] LAST CALL: XEP-0387 (XMPP Compliance Suites 2017)

[Ruslan N. Marchenko]

On 09.11.2017 23:54, Arc Riley wrote:
On Thu, Nov 9, 2017 at 12:30 PM, Florian Schmaus > wrote:


Fact is, if you would implement a new XMPP server without xep114,
you would
miss a lot of fun.


I haven't run an XMPP component since the early 2000's and I did not 
find it "fun". Quite the opposite actually, but this is beside the point.


I second that, have C2S driver disabled for ages, never came to a 
thought to enable it.


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

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

[Ruslan N. Marchenko]

Hi,


On 16.10.2017 20:38, Jonas Wielicki (XSF Editor) wrote:

This message constitutes notice of a Last Call for comments on
XEP-0313.

Abstract:
This document defines a protocol to query and control an archive of
messages stored on a server.

This Last Call begins today and shall end at the close of business on
2017-10-30.

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?

Yes

2. Does the specification solve the problem stated in the introduction
and requirements?

Yes

3. Do you plan to implement this specification in your code? If not,
why not?

Yes

4. Do you have any security concerns related to this specification?

No

5. Is the specification accurate and clearly written?
The first thing I stumbled upon while starting drafting implementation 
is - empty result.

?
?
0?
Or perhaps even ?

Also agree with pubsub - kind of gray area, pusub has its own semantic 
for synchronisation, with nature of pubsub being different from 
trackable archivable content.
Not a problem to archive headline messages as any other message type 
treating them all alike, but applying different logic for different 
services (subservice) is an overkill imo.


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

Re: [Standards] Proposed changes to OMEMO's use of PEP

[Ruslan N. Marchenko]

On 26.03.2017 00:01, Timothée Jaussoin wrote:

Hi,

It seems that this pull request brought some interesting discussions.
I'll try to clarify my position regarding this pull request.

Le vendredi 24 mars 2017 à 17:03 +0100, Andreas Straub a écrit :

Hey all,

this topic has been discussed at the summit and in other venues
before,
and now a proposal to abolish the devicelist and move all bundles
into
separate items in a single PEP node has been submitted. I have raised
my
concerns in those abstract discussions in the past, but now we have
something concrete we can discuss.

https://github.com/xsf/xeps/pull/458/files

While I recognize that the way we've been using PEP is somewhat
unorthodox, I see several severe issues with this newly proposed
approach.

Most importantly, this change effectively relies on OPTIONAL/MAY
behavior in PEP. PEP/pubsub do not mandate that the server has to
keep
around more than one item per node. Therefore, this change will
limit
the number of OMEMO devices a user can have active at the same time
to
the maximum number of items per PEP node as supported by the server,
which in the general case has to be assumed to be 1. The devicelist
is
an absolutely essential component of OMEMO, and it *has to* work
properly. Without it, we not only lose multi-device, but have to
deal
with severe reliability issues related to whichever device(s)
happen(s)
to be currently announced or not (i.e. messages only arriving at
random,
possibly frequently changing subsets of devices without the user
being
able to control this at all)

I agree with that and I trully think that this behavior needs to be clarified. 
It seems indeed that this OPTIONAL/MAY in the PEP
extension brought two points of view on how PEP can be seen. To me, if a server 
can store several items per PEP nodes (which is the
case on several XMPP servers already) then I see it as a "Pubsub service" 
available under a user JID.
  
Also, some XEPs like Microblog (0277) and Pubsub-Subscription (0330) are already relying on it and are implemented in clients. The work

that we are currently doing to modernize the Bookmark XEP (0048) also replies 
on the fact that each bookmark will be store in different
items under the same PEP node (to prevent the current race-condition issue that 
we have today).

As I understood this behavior was mostly crafted like this because it was 
working on existing servers implementations, especially for
Prosody that doesn't support persistance of items in its current stable release.

My understanding of this subject from your similar discussion here 
https://mail.jabber.org/pipermail/standards/2017-January/031839.html is 
that the only protocol-compliant way to determine it is getting/setting 
max_items to be more than 1. Which means client needs to identify 
following features support - item-ids, persistent-items, config-node and 
then from the config get or set max_items to the required number.


Where _required number_ will in this particular case be equal to number 
of devices to support. To get number of devices you need to get current 
number of items and either find own item there or set to current+1 and 
add own item. Or it could be pre-set to certain _reasonable_ number, and 
if fully occupied - to execute certain garbage collector and prompt 
extension/cleanup from the user.


Now, do I understand it right that this particular sequence of events 
and decisions is suggested to be offloaded to the server side as being 
too complicated for client to perform?



Furthermore, by eliminating the indirection via a separate
devicelist
node and subscribing to all bundles directly, a significant increase
in
traffic overhead is to be expected. Any time a bundle changes, all
contacts will receive the entire bundle. This happens frequently in
OMEMO. For example, whenever a new session is established, according
to
the XEP, the responder SHOULD change their bundle (removing the used-
up
prekey). Clients might also rotate their signed prekey regularly.
Any
time these things happen, all OMEMO-enabled contacts (and other own
devices) will receive the full bundle. Note that in most cases,
these
clients don't care at all about these events. The only times a
client
would actually want to be passively informed about changes is when
devices are newly created or removed entirely, which is the vast
minority of these events. (For reference, bundles with the suggested
number of prekeys (100) are around 9-10kb in size.)


See https://xmpp.org/extensions/xep-0060.html#owner-configure.

This behavior can be fixed by setting pubsub#deliver_payloads to false in the 
'urn:xmpp:omemo:0' node configuration. The clients will
then only get a small notification and not the whole bundle anymore, it can 
then retrieve the bundle manually if he needs it. Again
here we are relying on features that already exists. I can complete my pull 
request to enforce this behavior on node creation.


This proposal is also internally inconsistent. Some of 

Re: [Standards] Deprecating Privacy Lists (again)

[Ruslan N. Marchenko]

On 23.03.2017 14:18, Dave Cridland wrote:

On 22 March 2017 at 20:08, Ruslan N. Marchenko <m...@ruff.mobi> wrote:

On 22.03.2017 20:37, Sam Whited wrote:

On Wed, Mar 22, 2017 at 2:28 PM, Yann Leboulanger <aste...@lagaule.org>
wrote:

One nice feature we also don't have with blocking command is blocking a
while group.


Ah yes! I knew there was something else that I was forgetting to
address from last time.

I also think this is not a good thing; it is an abuse of roster
groups, and leads to an inconsistent experience across clients. It
also makes the UX incredibly frustrating. For example:

I block a group "work", but then I decide I want to talk to one of my
coworkers so I go to their chat, but it says they're blocked. I hit
unblock: what happens?


It's probably UX problem but not list per se.

If a protocol explicitly creates UX problems, it's a protocol problem.


List allows you creating overriding allow entry which will unblock single
person while keeping the group blocked (order matters).

There's no way for one client to inform another that this is not a
general standalone rule, but an explicit exception to a previous rule,
But there is, active list. Active list is local to client, default to 
user. Active cannot be intermixed with default, so if one client wants 
an exception - it may (just a quick guess) copy a list and set it active.
There're plenty of configurations client could apply. Although of course 
different implementations will probably treat lists differently. But if 
client allows raw list editing - user always has an option to apply 
whatever configuration he wants. Gajim is a good example of that - 
blocking option + raw editor.



however. There's no way to say that this exception is a temporary
case, rather than the norm. There's no way to indicate that this is
actually a general rule because this particular co-worker is also an
XSF member, and people in both groups are always unblocked.

I would much rather have clients using a simple interface that covers
the 90%, than not using a complicated one which fails to cover more
than 95%.

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

Re: [Standards] Deprecating Privacy Lists (again)

[Ruslan N. Marchenko]

On 22.03.2017 20:37, Sam Whited wrote:

On Wed, Mar 22, 2017 at 2:28 PM, Yann Leboulanger  wrote:

One nice feature we also don't have with blocking command is blocking a
while group.


Ah yes! I knew there was something else that I was forgetting to
address from last time.

I also think this is not a good thing; it is an abuse of roster
groups, and leads to an inconsistent experience across clients. It
also makes the UX incredibly frustrating. For example:

I block a group "work", but then I decide I want to talk to one of my
coworkers so I go to their chat, but it says they're blocked. I hit
unblock: what happens?


It's probably UX problem but not list per se.

List allows you creating overriding allow entry which will unblock 
single person while keeping the group blocked (order matters).


So - I'm against that. Priv.Lists is a very flexible and precise tool.


Does it unblock the entire group (oops,
everyone knows I'm online now and can start asking me work related
questions after hours), does it unblock just them? If it unblocks just
them, how does that work? Do I have to maintain a white list of "the
entire group is blocked, but this person is specifically unblocked"?

This becomes very complex very quickly, and is one of the reasons that
privacy lists are too complex; I also suspect it's very niche. This is
not a use case I think we should support.

—Sam
___
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] LAST CALL: XEP-0352 (Client State Indication)

[Ruslan N. Marchenko]

On 18.03.2017 11:16, Dave Cridland wrote:

On 18 March 2017 at 09:53, Florian Schmaus <f...@geekplace.eu> wrote:

On 18.03.2017 09:43, Dave Cridland wrote:

On 17 Mar 2017 21:52, "Ruslan N. Marchenko" <m...@ruff.mobi
<mailto:m...@ruff.mobi>> wrote:
 On 11.02.2017 21:43, Florian Schmaus wrote:
 It should be explicitly stated that the CSI state is *not*
 (because it
 can not) restored after a stream resumption. I've created a PR to
 address this: https://github.com/xsf/xeps/pull/402
 <https://github.com/xsf/xeps/pull/402>

 Why *not* btw? Device may detect the connection is dropped (by
 server) while still being inactive. The fact it waked from deep
 sleep does not indicate it's active.
 I convinced it should be quite opposite. The only reason to not
 being restored is because (at the moment) it is nonza and nonzas are
 not smacked.

 If handheld emits csi/csa events based on user interaction and not
 power-management events it may be a bit complicated *not*-restoring
 state and then pushing it back to inactive.
 The sole fact of resumption means all undelivered (eg. queued)
 stanzas are to be delivered - as on any other message delivery. Then
 it may continue sleeping as it was before.
 Unless it's really active now.

 Perhaps it should be kind of conditional statement - unless CSI is
 acked - the state *must not* be assumed to be either restored or
 reset - hence it's responsibility of the client to set it back to
 the desired state.


You can't rely on the state being acknowledged, because that would
require both sides to know that the client has seen the ack.

Does the server really need to know if the client received the ack?
Right now I think along the lines of:
- the server simply always restores the CSI state
- the client keeps track if the last CSI state change was acknowledged
- if it was not acknowledged, the client resets the CSI state to its
desired state

What am I missing here?


Well, yes, the client would have to always set the state unless it'd
seen the ack; that's the workaround. But in this case you might as
well simplify things and always set it anyway.

My point was to address the original intention to update XEP-0198 and 
other state-related XEPs - with proposal to update state-related XEPs 
with simple wording that "state is always preserved, but what is that 
preserved state depends on state change being acked by SM or other 
relevant mechanism, otherwise state on resumption is undefined".
Now, we know that stanzas are always acked - so everything IQ-driven is 
preserved. CSI - is nonza, and currently nonzas are not tracked by SM. 
So until SM is advanced to support nonzas as well - nonza driven state 
on resumption is undefined. If client has possibility to identify nonza 
acks by in-order-processing rule - it may consider nonzas as being acked 
hence the state on resumption to be known.


The idea is to avoid making additional fuss to enforce state to be 
either way on client or server side during resumption. Just keep it as 
is. And if you're not sure what is that 'as-is' - just set it explicitly.


Regards,
Ruslan
P.S> The PR comments touched compression topic. Compression is transport 
feature, it's negotiated before resumption. What is being resumed is XML 
document content/body, not framing/headers.



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

Re: [Standards] LAST CALL: XEP-0352 (Client State Indication)

[Ruslan N. Marchenko]

On 11.02.2017 21:43, Florian Schmaus wrote:

It should be explicitly stated that the CSI state is *not* (because it
can not) restored after a stream resumption. I've created a PR to
address this: https://github.com/xsf/xeps/pull/402

Why *not* btw? Device may detect the connection is dropped (by server) 
while still being inactive. The fact it waked from deep sleep does not 
indicate it's active.
I convinced it should be quite opposite. The only reason to not being 
restored is because (at the moment) it is nonza and nonzas are not smacked.


If handheld emits csi/csa events based on user interaction and not 
power-management events it may be a bit complicated *not*-restoring 
state and then pushing it back to inactive.
The sole fact of resumption means all undelivered (eg. queued) stanzas 
are to be delivered - as on any other message delivery. Then it may 
continue sleeping as it was before.

Unless it's really active now.

Perhaps it should be kind of conditional statement - unless CSI is acked 
- the state *must not* be assumed to be either restored or reset - hence 
it's responsibility of the client to set it back to the desired state.


So xep-0198 in current state is right to note the state may not be 
considered preserved for CSI. Although carbons... set by acked iq, why 
won't it be preserved? What is the rationale? Why one IQ (roster, 
blocking/privacy/visibility) is preserved and another (carbons) is not?


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

Re: [Standards] LAST CALL: XEP-0186 (Invisible Command)

[Ruslan N. Marchenko]

On 07.03.2017 12:31, Jonas Wielicki wrote:


I would like a rationale for why after going visible again, the session is
treated as before sending initial presence. This feels counter-intuitive to
me: I would expect all my contacts to see the presence I most recently sent to
those on my "visible list". While a client can surely implement it that way,
is there a rationale to not have it specified that way by setting the outbound
presence to the most recently sent during invisibility?
This thing I actually liked the most - very elegant, just send the 
presence you want to be after invisible. In the client it's simple (just 
re-send current presence). In the server it's simple (just broadcast and 
send probes).
I believe the rationale is consistency of the presence state. If server 
just rebroadcast last cached presence (even of cached for this 
connection) - it wouldn't be proper presence state since some(most?) 
implementations may stop sending presence once they received 
'unavailable'. And they are not obliged to re-send it on receiving the 
new one. So you may write - server must broadcast and probe but... this 
is what happens on initial presence.



What does a server do when a client does not send a  after going
visible when asked by peers to which the client has sent directed presence vs.
those to which the client has not sent directed presence?

If we follow XEP-0016 way - literally nothing.
Directed presence is special case anyway, and is required to be tracked 
regardless the visibility.


Secondly, what is the state of the Privacy Lists if they are used as a backing
store after the client goes offline during invisibility? Are those reset
automatically? This could use some clarification.

Invisibility is quite straight-forward command. It's just one priv.list 
item - presence-out. (if we ignore probe thingy). So
 =  hence to set is 
to add such item (auto-creating active list if necessary) and to unset 
is just remove any such item (autodeleting empty active list if necessary).
The same semantic as being using in blocking commands. Just with active 
list instead of default.
But yes, probe thingy. That changes the whole picture. Meaning normal 
priv.list backend can not be used as is, should be modified/extended to 
account for probe blocking (which is impossible with priv.lists - except 
total blackout case).


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

[Standards] xmpp namespaces registry lacks rosterver namespace

[Ruslan N. Marchenko]

Hi,


I've been trying to find a registration of the 
urn:xmpp:features:rosterver namespace and found it's only mentioned 
once(!) in RFC6121 and nowhere else - namely neither in 
https://xmpp.org/registrar/namespaces.html nor in 
https://xmpp.org/registrar/stream-features.html registry.


Is it not a real namespace? Or why is it having so little attention?


Regards,

Ruslan

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

Re: [Standards] LAST CALL: XEP-0186 (Invisible Command)

[Ruslan N. Marchenko]

On 28.02.2017 17:27, XMPP Extensions Editor wrote:

This message constitutes notice of a Last Call for comments on XEP-0186 
(Invisible Command).

Abstract: This document specifies an XMPP protocol extension for user 
invisibility.

URL: https://xmpp.org/extensions/xep-0186.html

This Last Call begins today and shall end at the close of business on 
2017-03-14.

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?

Not really, but is handy nevertheless for client implementation

2. Does the specification solve the problem stated in the introduction and 
requirements?

Yes

3. Do you plan to implement this specification in your code? If not, why not?

Yes

4. Do you have any security concerns related to this specification?

No, security section list them accurately

5. Is the specification accurate and clearly written?
Spec still refers to XEP-0016 and XEP-0126 however latest amendment 
(probe blocking) directly contradicts to those XEPs making it incompatible.

I think it should be called out in interoperability section (Chapter 5).
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] XEP-0186 typo

[Ruslan N. Marchenko]

Hi,


there's a typo in Example 8. Service discovery response - should have 
reversed direction (to/from).



Regards,

Ruslan

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

Re: [Standards] Bind 2.0 and Best Practices for Handling Offline Messages interoperability

[Ruslan N. Marchenko]

On 24.02.2017 13:10, Michal Piotrowski wrote:


Maybe initial presence should also be wrapped up inside bind2?


This could be handy. On the other hand how should this interoperate 
with RFC 6121 4.2.1. In this section it's "recommended" that the 
client first get's roster from the server and after that sends the 
initial presence.



Also how to set _extended_ privacy then (invisible/blocking commands)
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0280 (Message Carbons)

[Ruslan N. Marchenko]

On 23.02.2017 08:36, Sam Whited wrote:


I *think* I'm against continuing to reference 0334 here. While this
hint is theoretically useful for other specs (eg. if there were some
kind of pubsub-MAM-sync in the future that replaced carbons), I'm not
sure we need to try and make it that reusable, and having it live in
the spec that it's used for makes more sense to me (one less thing I
have to click through to and read when implementing). I don't think it
would greatly increase the complexity or length of this spec to
include it, and I'm half convinced that 0334 needs to be split up and
deprecated (it just feels like a lot of random stuff that doesn't
belong together, but we can discuss that over on its thread), so I
don't think this spec should rely on it.

I am a fan, however, of deduplicating and only having one hint (I
don't really care which, or what it's called;  sounds good
to me just because it's already in the spec).


Fully agree, from first to last word.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] MAM: misleading archiving node in examples

[Ruslan N. Marchenko]

On 21.02.2017 22:00, Kim Alvefur wrote:

Hi,

On Tue, Feb 21, 2017 at 09:35:51PM +0100, Ruslan N. Marchenko wrote:

If I understand it right - in absence of 'to' attribute on c2s - the server
itself is assumed as a recipient - i.e.  == .

No, the current account is assumed, so ...


In MAM case archiving node for the user is user's bare jid - hence proper
addressing should be ...

... this is equivalent.

https://xmpp.org/rfcs/rfc6120.html#rules-noto


If the server receives an IQ stanza with no 'to' attribute, it MUST
process the stanza on behalf of the account from which received the
stanza, [...]
Ops, ok, thanks for pointing out, now need to review if I messed it up 
in some recent implementations. *sigh*


--RR

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

[Standards] MAM: misleading archiving node in examples

[Ruslan N. Marchenko]

Good evening,


In the examples across XEP-0313 the IQs are all to-less.

If I understand it right - in absence of 'to' attribute on c2s - the 
server itself is assumed as a recipient - i.e.  == to='example.org' id='1'/>.


In MAM case archiving node for the user is user's bare jid - hence 
proper addressing should be type='set'>...


While both - server and bare are supposed to be handled by server, the 
semantic is different - one is executed on behalf of the user and 
another on behalf of the server.


So to recap - disco example targets bare jid - i.e. it's bare jid 
(storage node) which supports mam, and if it is implemented as separate 
service - querying server for archive is a bit misleading.


prefs on the other hand should be handled by server but then - shouldn't 
server as well respond to disco#info with mam feature - as indicator of 
supported prefs at least perhaps?



Regards,

Ruslan

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

[Standards] MAM: Conflicting storage prefs behaviour

[Ruslan N. Marchenko]

Good afternoon,


I'm preparing implementation of the mam and since there're very few 
details in the XEP-0313 about actual archiving, mostly about querying - 
i believe the archiving process is then left at the discretion of the 
implementers.



Now, to avoid storing multiple copies of the message for given server to 
me it makes sense storing message while it is being routed. Certain 
central server archiving. Probably not blindly archive everything but 
rather as a _union all_ of all user prefs. And retrieval will just query 
that central db and wrap message to necessary xml layers. Since there's 
no archive modification in the MAM scope - there's no reason not to do 
it and it should be quite efficient.


And here where the _potential_ conflict comes.

ro...@montague.lit informs server it should only archive messages to 
jul...@capulet.lit because he doesn't want to miss a thing by losing it 
in tonnes of interactions, or perhaps he wants certain privacy in his 
archive, who knows:



  

  jul...@capulet.lit

  


_Note: in the above I've missed  because xep does not require it. It says server must 
return it in the "result" but nothing about client sending full prefs bucket in 
"set"._

However mercu...@montague.lit informs server to store roster and probably some 
other prefs


  

  ro...@montague.lit


  tyb...@capulet.lit

  


Now, server will apparently store conversation between Romeo and Mercutio, the 
question is then - should server keep silent to Romeo that it has his other 
conversations?
If Romeo later changes his preferences to include those of Mercutio - should 
server reveal it actually has some messages to consume?
If yes - it exposes certain privacy risk: If I didn't ask to store message, and 
server stores them - then the other side requested them to be stored.
If no - it would require tracking storage prefs windows and apply them all the 
way through the time, or add metadata listing who was eligible user of the 
stored message at the time of storing it. Which still is a bit cumbersome.

Or the best practices here should be to never mix archives and keep a separate 
copy for each user according to his current preferences at any given time? 
Could user request to purge the archive?

On the other hands whole XEP says it's up to server what to store hence it may 
return absolutely different comparing to what it was asked for - prefs are 
rather hints (may/should) not orders (must).
Then perhaps in this particular implementation it would make sense to disable 
prefs and store everything instead to avoid the conflict/leak?

Regards,
Ruslan

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

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

[Ruslan N. Marchenko]

On Wed, Feb 15, 2017 at 11:39:33AM +0300, Evgeny Khramtsov wrote:
> 
> But we don't have these tools. XMPP is a "niche" protocol,
> 
Ok, so let's keep it niche protocol by generating standards for each and
every use case.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

[Ruslan N. Marchenko]

On 15.02.2017 08:26, Evgeny Khramtsov wrote:

Wed, 15 Feb 2017 08:21:39 +0100
"Ruslan N. Marchenko" <m...@ruff.mobi> wrote:

Well, high-load is always a "corner" case: a very few people need it.
That doesn't mean we should ignore it. For example, SIP folks never
ignore high-load.
I don't say load-balancing is corner case, merely suggest that 
load-balancing from non-suitable components is a corner case. 
Loadbalancing xmpp (or smpt, or SIP) with http-proxy - *is* a corner case.
Ideally I'd like loadbalancer to offload both tls and stream 
negotiation, to filter out stream-flood (similar to syn-flood) - eg. 
pass/relay connection to the pool only once initial handshake is 
complete (stream/to + tls/SAN). That allows me to have farm behind 
focusing only on processing streams for my domains. (I'll probably even 
implement it for clustering perf/ha solution).

But frankly, I still do not understand your position: are you arguing
the XEP is not needed or what?

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

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

[Ruslan N. Marchenko]

On 15.02.2017 04:24, Travis Burtrum wrote:


Really?  How many ports do you have to open?


At least 3 - 25, 465, 587

I have port 25 for SMTP

Lucky you

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

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

[Ruslan N. Marchenko]

On 15.02.2017 07:44, Evgeny Khramtsov wrote:


I'm not here to convince you using balancers or/and ssl offload, feel
free not to use them. The thing is load balancers exist and some people
want to use them for whatever reason.

Exactly and normally load-balancers are making balancing decision when 
accepting connection. Which is - stream header. Once it is balanced - i 
don't believe you're going to demux tcp stream and spread stanzas from 
single stream across multiple servers? In other words - load-balancing 
of xmpp has no problems whatsoever in the current state. SSL offload - 
yes, i believe it will require more sophisticated load-balancer which 
understands underlying protocol and is able to reverse-proxy it. Which 
is also the case for other start-tls based application protocols. And 
for which nevertheless loadbalacers do exist and thriving.
So the use case described above is - how to build loadbalancer with ssl 
offload for xmpp from components which don't speak xmpp. Which from my 
understanding is again a corner-case.

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

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

[Ruslan N. Marchenko]

On 14.02.2017 20:36, Evgeny Khramtsov wrote:

There is yet another use case: letting load balancers (haproxy, nginx,
etc) support tls themselves and route decrypted traffic to an XMPP
backend. Currently, haproxy and nginx don't support XMPP STARTTLS
(although a patch for nginx exists with unknown quality). So this
removes some burden from server admins.

Correct me if I'm wrong but I think you're speaking about ssl offload, 
not load-balancing. Load-balancing of unencrypted traffic always allows 
finer precision to persistence and load distribution.
SSL Offload on the other hand decreases security(encryption) domain, 
it's not end-to-end anymore, rather end-to-lb. And lb-to-server airgap 
allows eavesdropping by any network support personnel.
Of course if we're speaking of nginx/haproxy - management domain would 
probably overlap security domain (same person managing network, server, 
application, etc.) but then - why to load-balance at all?


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

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

[Ruslan N. Marchenko]

On 14.02.2017 15:25, Travis Burtrum wrote:

(airports, coffee shops etc), save roundtrips.  And this is the maybe,
most TLS libs I've seen it's easier to establish a direct TLS connection
than xmpp's custom STARTTLS.
Maybe it's because I'm not using high-level abstraction libs but with 
openssl the process is identical, unless you want to fall back to 
meaningless insecure defaults with wrappers.

STARTTLS was a good idea when it was still acceptable to have both
unencrypted and encrypted connections, because port sharing is good? :)
It's no longer acceptable to have unencrypted connections which makes
STARTTLS quite useless, and TLS and ALPN allow us to not only port share
with other XMPP ports, but with any TLS port, port sharing is good right?

It has nothing to do with port reuse, rather service binding. When I'm 
thinking how many ports I need to open on firewall to allow simple mail 
exchange - it just makes me feel sad an sorry for all the people who 
developed those standards. And all these stupid http->https redirection 
could be avoided if http supported starttls and you simply enforce it on 
server (upgrade required).


We have a service, service is bound to the port, service has ability to 
be secure - what else do we need? We're not going to abandon 
non-encrypted communication, encryption overhead simply does not make 
sense in some cases. Hell there's gtalk federation (yet) :) stream 
handshake already has all the necessary controls to make security 
mandatory. I understand that S2S and C2S on different ports is a legacy 
we can hardly get rid of it, although we've managed to get rid of port 
5223 by defining the way to require starttls.


Also one security drawback here - now to DoS by encryption abuse vector 
you need to negotiate stream before doing starttls - meaning you need to 
have handcrafted tool just for this protocol. With TLS on socket you can 
use anything which is able to open secure socket (probably related to 
the quote above?).


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

Re: [Standards] XEP-0198 stream resumption with too high 'h' parameter

[Ruslan N. Marchenko]

On Tue, Feb 14, 2017 at 02:19:57PM +0100, Michal Piotrowski wrote:
> 
> Why, there's general case in error handling section:
> 
>  Stream management errors SHOULD be considered recoverable;
>  however, misuse of stream management MAY result in termination of the
>  stream.
> 
> 
> Yes there is a general case, that's why I said it's not "clearly" defined.
>  
Ok, my implementation cannot handle with it, so to me this answer was
quite clear :) Just to abort connection, with no explanations and
reverences.
--RR
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0198 stream resumption with too high 'h' parameter

[Ruslan N. Marchenko]

On Tue, Feb 14, 2017 at 12:17:10PM +0100, Michal Piotrowski wrote:
> In XEP-0198 I didn't find any information what should happen if clients sends
> too high 'h' parameter. 
> 
> What should be the server response in this case? The safest is probably to
> close the stream with error indicating a policy violation.
> 
> Also what should happen if a client resumes a stream with such too high 'h'
> parameter? This is also not clearly defined in the XEP but I understand that
> the server should return a  response with some reason and allow the
> client to try again or bind the session without resumption. 
> 

Why, there's general case in error handling section:

 Stream management errors SHOULD be considered recoverable;
 however, misuse of stream management MAY result in termination of the
 stream.

So if your implementation can recover from this state - use it,
otherwise just close the stream.

Resume with higher number - again means most probably what is found - is not
correct session to resume, hence 

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

Re: [Standards] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

[Ruslan N. Marchenko]

On Mon, Feb 13, 2017 at 03:55:13PM -0600, Sam Whited wrote:
> On Mon, Feb 13, 2017 at 3:43 PM, Ruslan N. Marchenko <m...@ruff.mobi> wrote:
> > I don't understand what do we need to hide here by summoning port 5223 from
> > the oblivion.
> 
> This is another reason why I think that privacy/security statement
> needs to be removed; it just leads to this sort of confusion.
> 
> I think we're *not* hiding anything here, we're just saving a few
> round trips. That's the benefit I see to this XEP: If you know you're
> using TLS, just start using it, why bother negotiating an upgrade?
> 
Ok, perhaps it makes sense to save a roundtrip on some corner cases but
then again - if time is such a valuable commodity for this use case -
why on earth would one do SRV lookup with its indefinite response time
for recursive search and validation?

There's no overhead in implementation - calls to secure socket and
restart stream are all there, this xep just arranges them in different
order, while adding one more negothiation method and service definition.

> I understand that not everyone needs to save these round trips, but I
> see that as the primary benefit of this XEP for people who do need to
> save it; trying to frame it as a security thing will just confuse
> people or make them think that the existing STARTTLS stuff is "bad"
> somehow.
> 
> —Sam
> ___
> 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] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

[Ruslan N. Marchenko]

On 13.02.2017 21:57, Travis Burtrum wrote:

On 02/13/2017 02:26 PM, Ruslan N. Marchenko wrote:

So security here will be just in the sense "all or nothing" -
either you pass through (non-paranoid) or not (paranoid).

That's not true though, there are firewalls in practice today that only
allow HTTP on port 80, and only TLS on port 443, but do not MITM TLS.
Yes, and that's what written as XEP's use-case - how to abuse corporate 
firewall by masking im/p2p software to legitimate business traffic (https).
This is not fair, and if I were CSO who found out such "use-case" in the 
network I'd just ordered to block pass-through TLS pushing people to use 
either explicit or implicit (transparent) proxy.


With all due respect and honesty I thought times when there was separate 
port for encrypted/non-encrypted traffic are passed by replaced by 
start-tls concept.
 starttls feature is quite transparent and flexible, if 
someone strips it - server just refuses progressing the handshake.
I don't understand what do we need to hide here by summoning port 5223 
from the oblivion.


If TLS is MITM'd with a custom CA installed on your device then TLS
doesn't protect you from the MITM of course, and this won't address that.
___
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] LAST CALL: XEP-0368 (SRV records for XMPP over TLS)

[Ruslan N. Marchenko]

On 13.02.2017 19:58, Travis Burtrum wrote:

Boy am I glad you missed the last call deadline by a day so I don't have
to address your concerns. :)

On 02/12/2017 11:03 AM, Sam Whited wrote:

A minor nitpick: The requirements section isn't really requirements,
it's the actual main content of the spec.

Someone mentioned that before but didn't respond when I asked where they
should be, such as how it should be re-arranged.


In the introduction and security concerns there are claims that this
spec provides "perhaps increased security and privacy over using
STARTTLS". These claims use both passive language ("perhaps"), and I
don't think are actually true (it's only slightly less trivial to
detect that not-HTTPS is most likely being transmitted, and lots of
corporate firewalls do this). Since these are weak statements to begin
with, I'd like to see them taken out in case they mislead users. I
don't think it provides any value to the specification to include
claims like this anyways, true or false.

It would be nice if these statements could be removed before the
council votes; apologies for being late to the party in bringing this
up again.

It's worded in a passive way because it depends on the choices you make
with regard to the spec.  If you send ALPN, well then that's not any
additional privacy over STARTTLS, you are still announcing to the middle
boxes you intend to talk XMPP over this TLS connection.  As discussed
before, if you enforce STARTTLS regardless of stripping, well then
direct TLS that has no plain fallback doesn't give you extra security.

Also it was previously noted in the absence of DNSSEC only allowing
xmpp-* records through instead of xmpps-* had a similar effect to
STARTTLS stripping, which is true, but also SRV records have a TTL that
a client could keep across different networks, so that could also remove
this possibility for a man in the middle with control over DNS right?
Again up to the server administrator how high they want to set their TTLs.

Lastly I could not disagree more with "it's only slightly less trivial
to detect that not-HTTPS is most likely being transmitted, and lots of
corporate firewalls do this", unless you mean detecting with ALPN, I
think analyzing traffic patterns of the stream underlying TLS to pick
apart XMPP vs HTTP vs anything else would be insanely difficult, surely
it'd make most HTTP sites fail too.  I doubt any corporations implement


When corporate is paranoid for security they just deploy transparent 
mitm/bumping proxy with root CA installed on all corporate workstations 
and sniffing the traffic applying all the corporate security/dlp rules.
So anything what does not speak HTTP pretending to be HTTPS will just 
die there. So security here will be just in the sense "all or nothing" - 
either you pass through (non-paranoid) or not (paranoid).

anything like this currently, or honestly ever could.
___
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] LAST CALL: XEP-0280 (Message Carbons)

[Ruslan N. Marchenko]

On 09.02.2017 00:07, XMPP Extensions Editor wrote:

This message constitutes notice of a Last Call for comments on XEP-0280 
(Message Carbons).

Abstract: In order to keep all IM clients for a user engaged in a conversation, 
outbound messages are carbon-copied to all interested resources.

URL: http://xmpp.org/extensions/xep-0280.html

This Last Call begins today and shall end at the close of business on 
2017-02-22.

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?

yes

2. Does the specification solve the problem stated in the introduction and 
requirements?

yes

3. Do you plan to implement this specification in your code? If not, why not?

yes

4. Do you have any security concerns related to this specification?

no

5. Is the specification accurate and clearly written?
No, the no-copy use is ambiguous. Are private and no-copy equivalent? 
Are they complementing each other? what is the server behaviour when 
only one of them is provided?
I personally am in favour of  order for owner and no-copy hint 
for remote party. And then - should server always strip  
before routing? Should it replace it with  hint?


Your feedback is appreciated!
___
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] LAST CALL: XEP-0352 (Client State Indication)

[Ruslan N. Marchenko]

On 09.02.2017 00:07, XMPP Extensions Editor wrote:

This message constitutes notice of a Last Call for comments on XEP-0352 (Client 
State Indication).

Abstract: This document defines a way for the client to indicate its 
active/inactive state.

URL: http://xmpp.org/extensions/xep-0352.html

This Last Call begins today and shall end at the close of business on 
2017-02-22.

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?

Yes, certainly, see google:queue to address this same gap

2. Does the specification solve the problem stated in the introduction and 
requirements?

Yes

3. Do you plan to implement this specification in your code? If not, why not?

Yes

4. Do you have any security concerns related to this specification?

No

5. Is the specification accurate and clearly written?

Excuse me my ignorance if it was clarified before but...
I still don't understand rationale behind choosing nonza. Server may 
wish to route/propagate the stanza to connected services/components to 
shut up and don't bother the user. After all it's client state 
indication, not stream state.
The only benefit of using nonza (apart from the size) is that after 
sending  client may just go sleeping without waiting for 
iq/response to digest tcp queue.
But with in-order processing requirements - server will process nonza 
after all queued stanzas, which means it actually makes sense waiting 
for iq/response as a confirmation of the active state closure on the 
given stream.
I.e. to be sure whatever comes in after that is really important, not 
leftovers of the previous active state, hence worth waking up.
Aside from that it lacks explicit instructions to add  tag to 
any deferred/queued/held stanzas.
And then "In-order processing" section misses this case for any such 
delayed stanzas should be delivered(flushed) in-order whenever stanza 
which could not be delayed needs to be delivered. This is maybe obvious 
from overall protocol specification but if someone volunteers to 
implement just a feature - there could be concerns/misunderstandings.

Your feedback is appreciated!
___
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] RFC 6120 vs. XEP

[Ruslan N. Marchenko]

On 08.02.2017 21:42, Evgeny Khramtsov wrote:

Wed, 8 Feb 2017 20:06:19 +0100
"Ruslan N. Marchenko" <m...@ruff.mobi> wrote:


RFC restricts nowhere
binding process to this extension

Actually it does, Section 14.4:


14 is a namespace section, so apparently it defines namespace relevant 
to the given RFC.



A URN sub-namespace for resource binding in the Extensible Messaging
and Presence Protocol (XMPP) is defined as follows.  (This namespace
name adheres to the format defined in [XML-REG].)
URI: urn:ietf:params:xml:ns:xmpp-bind

Here, the word "extension" is omited, so it will be harder to juggle
with words pretending you're making an argument ;)

I still don't see it as a requirement. Requirements are in section 7.
And here real noncompliance lays afaik just at 7.3.2, SM does not follow 
this rule for obvious reason.
Although stream restart is not a big overhead and again - does not 
mandate session restart.

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

Re: [Standards] RFC 6120 vs. XEP

[Ruslan N. Marchenko]

Allow me to put my two cents

On 08.02.2017 09:53, Evgeny Khramtsov wrote:

Wed, 8 Feb 2017 08:19:17 +
Dave Cridland  wrote:


Right, I understand, and largely agree. I might scribble a draft to
address this, by clarifying what we really meant here.

I see also two issues here ;)

1. RFC6120, section 7.1 says:


After a client authenticates with a server, it MUST bind a specific
resource to the stream so that the server can properly address the
client.

Thus, a client is unable to resume a session in any case.
I think the misunderstanding roots in similarity of the BINDing 
requirement and BINDing process (using IQ with BINDing extension namespace).
Resumption *IS* doing binding. After resumption - connection is uniquely 
bound and addressable. No RFC violation.
In fact server implementation may execute similar calls to bind newly 
authenticated connection to existing session.


2. While almost everybody here argued that "resource binding" is any
binding mechanism, including Bind2, RFC6120 clearly defines "resource
binding":

Section 7.3.1:


The parties to a stream MUST consider resource binding as mandatory-
to-negotiate.
Yes, this is where SM should be mandatory to negotiate. Currently it's 
just written as a fallback condition (failure to resume must be followed 
by proper binding)

And section 7.1 defines:


The XML namespace name for the resource binding extension is
'urn:ietf:params:xml:ns:xmpp-bind'.
Yes, for the extension which is described by RFC, RFC restricts nowhere 
binding process to this extension, just tells it's mandatory to negotiate.
I.e. any RFC6120 compatible server and client MUST support this 
extension for the binding purpose.

But aren't limited to that.

In my book, "resource binding" is exactly something within
'urn:ietf:params:xml:ns:xmpp-bind' namespace, unambiguously.
___
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
___