> 1. Is this specification needed to fill gaps in the XMPP protocol
> stack or to clarify an existing protocol?
Yes, it allows to negotiate the used channel-binding rather than just guessing
what type the server might support.
> 2. Does the specification solve the problem stated in the
> Yes, I have implemented this for xmpp.js -- except for "tasks" which I have
> not implemented and I think there are no official profiles of, making that a
> somewhat more risky area of the spec.
There is a task defined in XEP-0480 (for upgrading server-stored SCRAM hashes,
for example from
es to our Monal pushservers.
[1] https://xmpp.org/extensions/xep-0474.html#sect-idm45721839708464
Am Samstag, 28. Oktober 2023, 15:40:09 CET schrieb Matthew Wild:
> On Fri, 6 Jan 2023 at 16:42, Thilo Molitor wrote:
> > No matter how: now I can MITM the TLS connection, but channel-binding w
.
-tmolitor
[1] https://notes.valdikss .org .ru /jabber.ru-mitm/ (note the spaces to
counter spam filters)
[2] https://xmpp.org/extensions/xep-0474.html#reqs
Am Freitag, 6. Januar 2023, 17:40:55 CEST schrieb Thilo Molitor:
> Hi Dave,
>
> > Not using PLAIN is insufficient - clients
Hi all,
XEP-0388 seems to be stuck again, this time in the editor pipeline.
Is there anything I can do to help here (short of becoming an editor myself)?
What is the current editor situation at all?
My SASL2 accompanying ProtoXEP seems to be stuck, too, and never made it to
the inbox:
> There is a very obvious solution to this which everyone seems to be
> overlooking: we need a new element with a guaranteed unique, non-spoofed
> UUID; should a server feel the need to do bad things, it can set the
> 'spoofed' attribute to true and then clients can act accordingly.
what entity
+1 for an informational xep detailing how to reference messages in various
scenarios (muc, 1:1 etc.).
Am Dienstag, 21. Februar 2023, 21:17:23 CET schrieb Marvin W:
> Hi,
>
> This is feedback for the latest PR to XEP-0359.
>
> > The value of origin-id is spoofable and hence MUST not be used
> Minor nitpick : section 9.1 still references the :1 namespace.
Oh, that slipped through, thanks for spotting this!
> I think it would be nice to add a historical note/depreciation
> notice/whatever of what was that :1 namespace for future references.
I'm not shure where to add that, for now
tps://github.com/iNPUTmice/Conversations/blob/master/src/main/java/eu/sia
> cs/conversations/xmpp/jingle/JingleRtpConnection.java#L1371
> On Wed, Jan 25, 2023 at 10:22 PM Thilo Molitor wrote:
> > Am Mittwoch, 25. Januar 2023, 17:12:06 CET schrieb Daniel Gultsch:
> > > I'd get
In
> favor of wording around proceed being carbon copied)
But clients implementing the old :0 version won't stop ringing if I accept the
call on a device on the same account implementing the new :0 version, no?
-tmolitor
>
> On Wed, Jan 25, 2023 at 3:49 AM Thilo Molitor wrote:
> &g
As discussed in the XSF MUC, I've updated XEP-0353 to use the old :0
namespace, but still incorporate all features of the :1 namespace.
I had to water down some MUST of :1 to SHOULD to accomplish this.
I've also merged the and elements into the same message
stanza in order to maintain
I did not meant to be rude, it was merely a sign of surprise.
-tmolitor
Am Mittwoch, 18. Januar 2023, 21:56:43 CET schrieb Peter Saint-Andre:
> Or: hey, it's great that we already did the work, let's merge it!
>
> On 1/18/23 12:46 PM, Thilo Molitor wrote:
> > So the PR is lyin
So the PR is lying around for ~5 years and nobody merged it even if it was
approved?
Why that?
-tmolitor
Am Mittwoch, 18. Januar 2023, 18:45:30 CET schrieb Florian Schmaus:
> On 18/01/2023 17.26, Thilo Molitor wrote:
> > In Appendix F: Requirements Conformance all our XEPs refer to
In Appendix F: Requirements Conformance all our XEPs refer to RFC 2119 defining
"MUST", "SHALL" etc.
But since RFC 2119 does not specify which case should be used for these
keywords, a XEP using "shall" or even "sHaLl" uses normative keywords, no?
I think we should add a reference to RFC 8174
> Dave approved the PR last week here:
> https://github.com/xsf/xeps/pull/1214#pullrequestreview-1236512706
Great, I've not hallucinated! At least partly (I thought he did so on list).
-tmolitor
___
Standards mailing list
Info:
To bring this to the list, too:
I thought Dave did approve the PR #1214 here on list, but could not find his
mail. Maybe I just hallucinated the approval?
So @dwd: could you either please approve the PR or tell us (here on list) what
to change?
It would be super cool to move forward with SASL2
To bring this from the Github PR [1] to the list, too
> @fippo @stpeter Is this ok to be merged in its current state?
[1] https://github.com/xsf/xeps/pull/1262
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Hi Dave,
> Not using PLAIN is insufficient - clients have to only use SCRAM, and in
> particular, variants of SCRAM that are considered secure.
Not exactly true. One could design a channel-binding downgrade detection for
SASL-EXTERNAL using client certificates, too.
But I wanted to start with
Yeah, that discussion in the summer was really long, but much appreciated by
me!
The SSDP XEP mainly tries to fill the gap described in XEP-0440 Security
Considerations [0]:
> If a client signals to the server that he does not support channel binding,
because it found no mutual supported
Since PR #1214 [0] (SASL2, XEP-0388) got finally approved by Dave, I want to
bring some follow-up PRs to your attention:
1.) PR #1248 [1]: Overhaul SCRAM Upgrade ProtoXEP to include definition of
SASL2 upgrade tasks.
This ProtoXEP defines SASL2 upgrade tasks.
I originally added these to SASL2
Well, thanks for all your explanations and recommendations.
I'll go with "This identifier MUST be globally unique, and therefore it is
RECOMMENDED to use UUIDv4."
I updated the PR accordingly: https://github.com/xsf/xeps/pull/1262
-tmolitor
Am Donnerstag, 5. Januar 2023, 14:27:22 CET schrieb
Am Samstag, 19. November 2022, 20:08:17 CET schrieb Dave Cridland:
> > Incidentally, if SASL2+BIND2+etc take over the world, then you'll be
> > repeating all these stream features and/or having all stream features
> > nesting eternally inside each other.
> >
> > I don't see how adds any need for
Am Samstag, 19. November 2022, 18:15:17 CET schrieb Daniel Gultsch:
> On Sat, Nov 19, 2022 at 5:55 PM Florian Schmaus wrote:
> > Why not simply
> >
> >
> >
> >
> >
> > SCRAM-SHA-1-PLUS
> > PLAIN
> > SCRAM-SHA-1
> >
> >
> >
> >
> >
> >
Hi Kim,
> I don't believe randomizing mechanisms helps. An attacker can simply
> connect multiple times and check if things vary or stay the same.
>
> And given that attackers have unlimited IP addressees via proxies or
> compromised machines, I don't think rate limiting helps much either.
Hmm
This series of mails concluded that channel-binding together with SCRAM (or
OPAQUE) provides for the highest additional security beyond TLS.
But channel-binding can only be used, if a MITM isn't able to deactivate it
before it can detect the MITM.
The security considerations of XEP-0440 (
Using the PLAIN mechanism will send the password in cleartext, only protected
by TLS itself, the server will always see your cleartext password and channel-
binding isn't supported by PLAIN, too.
That's fine, if you deem TLS to be always secure and your server to never be
evil or compromised.
One topic not directly connected to SASL2, but to channel-binding and SCRAM in
general, is the security of TLS.
When discussing about whether PLAIN is a good choice or whether channel-
binding has any benefit or even if SCRAM is needed, the underlying problem ist,
that everyone has another view
As with SASL mechanisms, today various different channel-binding types with
varying strength can be used.
SCRAM and the upcoming OPAQUE mechanism can use channel-binding to make sure
the TLS channel is MITM-free (the "-PLUS" variants of SCRAM and OPAQUE).
You'll need channel-binding to make
Previously the SASL2 XEP used a base64 encoded challenge-response flow for it's
tasks.
That allows challenges and responses to be of arbitrary payload, but makes it
difficult to encode information when defining SASL2 tasks for XMPP in future
XEPs.
One example we came across ourselves are the
This consists of various sub-parts.
All of these assume, that the server does not store passwords in plaintext,
but in hashed form of some sort (e.g. SCRAM, OPAQUE etc.).
There are various reasons to not let servers store passwords in plaintext, if
possible. Prosody, for example, stores it's
Again, MattJ already explained this well: https://mail.jabber.org/pipermail/
standards/2022-October/038998.html
SASL2 allows for inlining additional elements into the authentication flow.
That, like pipelining, reduces round-trip-times.
To let clients distinguish, which features can be inlined
I'm trying to rephrase and sum up here, what MattJ already said: https://
mail.jabber.org/pipermail/standards/2022-October/038998.html
Stable client-identifier:
This allows per-device tokens or even passwords.
It allows to present users with a list of devices that currently have access
to their
'm pretty happy with what we have working.
-tmolitor
Am Donnerstag, 20. Oktober 2022, 13:49:50 CEST schrieb Marvin W:
> Hi Thilo,
>
> On Wed, 2022-10-19 at 21:41 +0200, Thilo Molitor wrote:
> > I want us to move away from that "PLAIN is sometimes needed, let's
> > suppo
Hi Marvin,
> > I've split out the SCRAM upgrade task definition into a new ProtoXEP:
> > https://
> > github.com/tmolitor-stud-tu/xeps/tree/scram-upgrades
> > Rendered version:
> > https://dyn.eightysoft.de/final/xep-scram-upgrade.html
>
> Just wanted to mention that this specification isn't
Hi Matthew,
> There are deployments that require PLAIN. That is unlikely to change
> (ever). However this doesn't stop clients from being smart, e.g. by
> pinning support for SCRAM and refusing to downgrade. I don't know if
> any clients actually do this.
Yes, those deployments do exist.
But I
I've pushed a new commit partly addressing some of Dave's concerns: https://
github.com/xsf/xeps/pull/1214/commits/2a0a894f8ea606d9bbf894f85c3c306c8166cb54
Up to date rendering: https://dyn.eightysoft.de/final/xep-0388.html
Up to date diff: https://dyn.eightysoft.de/final/xep-0388-diff.html
Am Mittwoch, 19. Oktober 2022, 16:32:55 CEST schrieb Dave Cridland:
> Small point: GS2 doesn't ever allow clients to know if channel binding is
> proven, since the channel binding data is passed in the clear to the
> server. It does prove the server saw the channel binding data as sent by
> the
Hi Marvin,
> I think the specification partially exaggerates on what it is able to
> actually achieve security-wise.
>
> The requirements say: "Allow detection of SASL mechanism downgrades
> even if no channel-binding is in use.". However, as this is an
> extension to SCRAM, it only allows
Hi Peter,
> In any case, if the client has a local policy not to use PLAIN (or other
> mechanisms that it considers to be too weak), then it simply wouldn't
> use those in case of a downgrade attack. Similar policies are in place
> already for things like old versions of TLS, see here:
>
Hi Daniel,
Am Mittwoch, 19. Oktober 2022, 09:23:10 CEST schrieb Daniel Gultsch:
> > But that leaves clients not able to implement this type, or any
> > channel-binding at all, vulnerable to downgrades of channel-binding types
> > and SASL mechanisms.
> This specification protects clients that are
Hi Daniel,
Daniel Gultsch wrote:
> Inline + User-Agent good. Very skeptical on forbidding PLAIN and the
dependency on channel binding.
It's not forbidding PLAIN, but highlights what is already described in RFC
6120 section 13.8.3, but seems to have been forgotten: PLAIN should not be
used if
Thanks for your feedback Dave!
Am Montag, 17. Oktober 2022, 15:36:56 CEST schrieb Dave Cridland:
> Any attacker able to manipulate the data coming from the server such that
> the client sees a restricted set of TLS channel bindings can also
> manipulate the data coming from the server such that
+1 for MUST
Am Samstag, 27. August 2022, 11:41:38 CEST schrieb Dave Cridland:
> On Wed, 24 Aug 2022 at 07:56, Daniel Gultsch wrote:
> > And yes we are currently implementing it. That's why I’m providing
> > feedback on the XEP. And yes we are using it with compression and yes
> > we do
Why an extra XEP instead of extending XEP-0353 to include group calls?
I recently reworked the whole XEP-0353 and given that this includes a
namespace bump, it would be easy to extend it to include other invite types
alongside the jingle invites already included.
Having two XEPs overlapping
> +1 on merging. There’s been a lot of foundational improvements since
> mid-2014 that we can safely rely on now, so these changes make sense.
Thanks Lance for your feedback!
> There is one scenario that the :0 version with its split accept/proceed
> allows that I don’t think the :1 does: stop
Hi all,
I reworked the Deferred XEP-0353 spec and modernized it quite a lot (and
bumped the namespace): https://github.com/xsf/xeps/pull/1128
Because of that I want to discuss this on this list, too.
Quick introduction for lazy ones:
In the old protocol the responder had to send an element to
t;
> at all if it's only one message, the direction won't matter, no?
>
> —Sam
>
> On Fri, Aug 27, 2021, at 09:34, Thilo Molitor wrote:
> > When the user first sets up a new account, we query the archive with
> > end= and RSM {max=1, before=""}
>
> ___
Am Freitag, 27. August 2021, 17:20:17 CEST schrieb Andrew Nenakhov:
> пт, 27 авг. 2021 г. в 18:08, Thilo Molitor :
> > That's not quite right, you can use XEP-0353 together with XEP-0198 and/or
> > XEP-0313 to make VoIP work on iOS.
>
> No. You can not.
>
> In a sense
Am Freitag, 27. August 2021, 13:12:44 CEST schrieb Sam Whited:
> Thanks JC!
>
> You're right, I should have mentioned gaps. It's still possible to
> have them in a desktop client because it could always close before it
> finishes paging through catching up on history. I had planned to solve
>
Am Freitag, 27. August 2021, 16:03:19 CEST schrieb Philipp Hörist:
> Thilo Molitor schrieb am Fr., 27. Aug. 2021, 15:35:
> > every MUC catchup delays only "live" message stanzas for that MUC, not
> > other MUCs or 1:1).
>
> How can you delay live messages fro
Hi Sam et al,
for Monal we do something a bit different (a mixture of what you wrote and what
JC wrote):
When the user first sets up a new account, we query the archive with
end= and RSM {max=1, before=""}
The stanza-id of this message is then used as sync point the next time Monal
has to do
> Not quite. XEP-0430 is a (rather weak) imitation of the XEP-SYNC which was
> already done (and implemented) when Inbox was proposed. It supports
> delivered/read/unread messages, active calls in chat (without it, VoIP
> calls won't work on iOS)
That's not quite right, you can use XEP-0353
I think monal will be part of this, too
Am 22. Februar 2021 20:03:21 MEZ schrieb Florian Schmaus :
>On 2/11/21 1:42 PM, Paul Schaub wrote:
>> Hey everyone!
>>
>> Tomorrow will be new years eve in the Chinese calendar. The Berlin
>XMPP
>> Meetup celebrated the beginning of the "year of the ox" by
> 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
This is for Monal, an iOS and MacOS xmpp client:
As developers tend to be a bit too proud of their own peace of software we
asked our users for their honest opinion of Monal. We did not expect this:
For a while macOS was in really bad place when it came to XMPP clients. Now,
in the
Georg, you seem to forget the push that is involved.
I think most of your depicted problems would go away if the client would send
a (XEP-0198) ping upon receiving a push and, if that ping does not succeed,
decide that the connection is dead.
That way it won't stick to an old half-dead
Hi Dave.
> 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
> If you have an XMPP product or public project, do you claim compliance with
> XEP-0423?
For Monal we are aiming for compliance in the long run.
- tmolitor
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
>* Use AES256/CBC to encrypt SCE payload.
Why use CBC and not GCM for extra robustness?
- tmolitor
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
You forgot to mention one notification type which is particularly useful in
this context:
You can use a Notification Service Extension to modify alert type notifications
before they are displayed to the user.
This way your notifications won't be throttled or delayed by hours and you
don't have
> > HTTP Upload and OOB are mentioned, but it is not said how to use them
> > together (I am thinking about the ugly hack of body == oob url). We
> > might want to detail this or point somewhere that describes it, as much
> > as I dislike it.
>
> I very much dislike it myself, but as of right now
B
Am Montag, 22. Juli 2019, 15:38:00 CEST schrieb Tedd Sterr:
> There appears to be a lack of interest, which is fair enough, but just to
> check opinion…
>
> Reply with a choice from one of the below; or don't - I'm not your boss.
>
> A. I'm not interested, leave me alone.
> B. I'd probably
Dave's suggestions are more or less what I configured on my private server and
are very sane imho:
On my private server I'm using prosody and configured a TCP read timeout of 10
minutes and I'm using 0198 stream management (all my clients are gajim, monal,
chatsecure or conversations).
On TCP
Wiktor's mail provider uses a DMARC record with policy "quarantine", which
means that Wiktors mails delivered through mailinglists will be dropped into
the spam folder by the receiving side or ignored at all.
https://www.dmarcanalyzer.com/de/dmarc-de/dmarc-record-check/?dmarcdns%5Btype
Thanks, noted :)
-- tmolitor
Am Sonntag, 17. Februar 2019, 19:48:36 CET schrieb Jonas Schäfer:
> On Sonntag, 17. Februar 2019 13:59:54 CET Thilo Molitor wrote:
> > If XEP-0013 is used as indicator that the device wants to use MAM to
> > retrieve messages, this in turn can be use
Does anyone of you use XEP-0013 in your client other than for purging offline
messages when you support MAM?
If this is the only practical usecase of XEP-0013 I'm planning to use the
purging of messages as (strong) indicator that a client uses MAM and as such
doesn't want the server to return
Sorry for my last message! I replied to the wrong thread...
So here is the correct reply :)
As I said already in another thread:
https://mail.jabber.org/pipermail/standards/2018-October/035387.html :
This XEP needs at least a note discouraging the use of the fields "message-
sender" and
As I said already in another thread:
https://mail.jabber.org/pipermail/standards/2018-October/035387.html :
This XEP needs at least a note discouraging the use of the fields "message-
sender" and "message-body" because of privacy implications.
In the wild the field "message-body" is left empty
> Appserver might take notice that app didn't wake up after three
> content-update notification and send an alert notification on fourth
> attempt. We don't do that, however.
Well, that wouldn't make for good UX at all. Push notifications are sent for
non-body messages, too. Having an alert
for a super nice UX but at least it is working.
Thilo
Am 2. Oktober 2018 18:59:17 MESZ schrieb "Ненахов Андрей"
:
>вт, 2 окт. 2018 г. в 21:28, Thilo Molitor :
>>
>> This XEP needs at least a note discouraging the use of the fields
>"message-
>> sender" and &q
This XEP needs at least a note discouraging the use of the fields "message-
sender" and "message-body" because of privacy implications.
In the wild the field "message-body" is left empty for low priority pushes (in
short: pushes not related to message stanzas containing a body) and set to
This sounds interesting.
Did someone implement it?
Thilo
Am Dienstag, 2. Oktober 2018, 13:49:51 CEST schrieb Jonas Schäfer:
> XEP-0390 (Entity Capabilities 2.0) has been Deferred because of
> inactivity.
>
> Abstract:
> This document overhauls the XMPP protocol extension Entity
> Capabilities
I think I should give you a real example where ISR really matters:
Under iOS you can not run your app in the background and keep it permanently
connected. And push doesn't always wake up your app in the background (there
are *some* circumstances which allow this but much more exceptions).
So:
Maybe it would be better if the traveling person would be using smacks
(XEP-0198).
Short network outages are effectively "healed" by smacks and should not result
in presence flapping.
The client and server must support smacks, though.
Thilo Molitor
Am Freitag, 20. Oktober 2017
I don't like the idea of different "message classes".
It is difficult to define classes that every client developer is happy with.
And new XEPs could add the need for more classes, too.
Every time, a new class is defined, this has to be added to the XEP and
implemented on the server side.
Every
I'd rather suggest something less client specific.
The requirements which stanzas are high priority and need special treatment
vary from client to client.
Letting the server choose, which stanzas belong into which category, seems to
be the wrong way.
My proposal (well...essentially it's
76 matches
Mail list logo
