Re: [Standards] Proposed XMPP Extension: DNS Queries over XMPP (DoX)

[Travis Burtrum]

On 3/12/19 4:08 PM, Jonas Schäfer (XSF Editor) wrote:
> The XMPP Extensions Editor has received a proposal for a new XEP.
> 
> Title: DNS Queries over XMPP (DoX)

Thanks Jonas!

If anyone wants to poke at a JID running this feel free to send queries
to d...@moparisthebest.com/listener which is running code from here:

https://github.com/moparisthebest/jDnsProxy/tree/dox

If you are feeling extra XMPP-y set it up on your router and run all
your DNS queries over XMPP. (or run a resolver yourself)

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

[Standards] Proposed XMPP Extension: E2E Authentication in XMPP: Certificate Issuance and Revocation

[XSF Editor]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: E2E Authentication in XMPP: Certificate Issuance and Revocation
Abstract:
This specification defines a way for a certificate authority to serve
certificate signing requests via XMPP in order to issue X.509
certificates for the use in end-to-end and c2s SASL EXTERNAL
authentication.

URL: https://xmpp.org/extensions/inbox/eax-cir.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] UPDATED: XEP-0410 (MUC Self-Ping (Schrödinger's Chat))

[XSF Editor]

Version 0.3.0 of XEP-0410 (MUC Self-Ping (Schrödinger's Chat)) has
been released.

Abstract:
This protocol extension for XEP-0045 Multi User Chat allows clients to
check whether they are still joined to a chatroom.

Changelog:
Incorporate council feedback: use @by on error elements (gl)

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

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Proposed XMPP Extension: DNS Queries over XMPP (DoX)

[XSF Editor]

The XMPP Extensions Editor has received a proposal for a new XEP.

Title: DNS Queries over XMPP (DoX)
Abstract:
This specification defines an XMPP protocol extension for sending DNS
queries and getting DNS responses over XML streams. Each DNS query-
response pair is mapped into an IQ exchange.

URL: https://xmpp.org/extensions/inbox/dox.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] NEW: XEP-0415 (XMPP Over RELOAD (XOR))

[XSF Editor]

Version 0.1.0 of XEP-0415 (XMPP Over RELOAD (XOR)) has been released.

Abstract:
This specification defines an XMPP Usage of REsource LOcation And
Discovery (RELOAD). The XMPP usage provides an ability for XMPP
clients to discover other peers' location through the peer-to-peer
overlay. Once a peer location is determined, the RELOAD AppAttach
method is used to establish a direct connection between peers through
which XMPP streams are exchanged.

Changelog:
Accepted by vote of Council on 2019-02-27. (XEP Editor (jsc))

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

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] NEW: XEP-0416 (E2E Authentication in XMPP)

[XSF Editor]

Version 0.1.0 of XEP-0416 (E2E Authentication in XMPP) has been
released.

Abstract:
This specification describes how X.509 certificates can be used for
end-to-end authentication in XMPP.

Changelog:
Accepted by vote of Council on 2019-02-27. (XEP Editor (jsc))

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

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] UPDATED: XEP-0156 (Discovering Alternative XMPP Connection Methods)

[XSF Editor]

Version 1.2.0 of XEP-0156 (Discovering Alternative XMPP Connection
Methods) has been released.

Abstract:
This document defines a DNS TXT Resource Record format for use in
discovering alternative methods of connecting to an XMPP server.

Changelog:
Add information about CORS header usage and requirements (wk)

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

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] UPDATED: XEP-0001 (XMPP Extension Protocols)

[XSF Editor]

Version 1.23.0 of XEP-0001 (XMPP Extension Protocols) has been
released.

Abstract:
This document defines the standards process followed by the XMPP
Standards Foundation.

Changelog:
Clarify proposing Deferred XEPs for advancement to Draft and introduce
the role of Document Shepherd. (rm)

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

Note: The information in the XEP list at https://xmpp.org/extensions/
is updated by a separate automated process and may be stale at the
time this email is sent. The XEP documents linked herein are up-to-
date.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] EAX

[Daniele Ricci]

I found it in the spam folder. Thank you and sorry for the off-topic :-)

On Tue, Mar 12, 2019 at 7:41 PM Wiktor Kwapisiewicz  wrote:
>
> On 12.03.2019 19:17, Thilo Molitor wrote:
> > (...) Wiktors mails delivered through mailinglists will be dropped into
> > the spam folder by the receiving side or ignored at all.
>
> This varies from mailing list to mailing list.
>
> For example some IETF Mailing Lists (e.g. OpenPGP) when mangling the
> e-mail they also change "From" header so that there is no issue with the
> DKIM signature.
>
> https://lists.sr.ht/ uses a different approach - they leave the mail
> unmodified, just append List-* headers and relay it to all subscribers.
> This way the mail still passes DKIM checks. (Example: click "details" on
> this thread [0]).
>
> Kind regards,
> Wiktor
>
> [0]:
> https://lists.sr.ht/~sircmpwn/sr.ht-dev/%3C20190108111256.9088-1-wiktor%40metacode.biz%3E
>
> --
> https://metacode.biz/@wiktor
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___



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

Re: [Standards] EAX

[Wiktor Kwapisiewicz]

On 12.03.2019 19:17, Thilo Molitor wrote:

(...) Wiktors mails delivered through mailinglists will be dropped into
the spam folder by the receiving side or ignored at all.


This varies from mailing list to mailing list.

For example some IETF Mailing Lists (e.g. OpenPGP) when mangling the 
e-mail they also change "From" header so that there is no issue with the 
DKIM signature.


https://lists.sr.ht/ uses a different approach - they leave the mail 
unmodified, just append List-* headers and relay it to all subscribers. 
This way the mail still passes DKIM checks. (Example: click "details" on 
this thread [0]).


Kind regards,
Wiktor

[0]: 
https://lists.sr.ht/~sircmpwn/sr.ht-dev/%3C20190108111256.9088-1-wiktor%40metacode.biz%3E


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

Re: [Standards] EAX

[Wiktor Kwapisiewicz]

On 12.03.2019 18:35, Daniele Ricci wrote:

Did I lose the email by Wiktor? Or did he replied to you only?



I bet it's due to the mailing list modifying e-mails. That breaks DKIM 
signatures. I guess if you checked your SPAM folder my e-mail about SPIM 
would be there.


Kind regards,
Wiktor

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

Re: [Standards] EAX

[Thilo Molitor]

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
%5D=dmarc&dmarcdns%5Bdomain%5D=metacode.biz&g-recaptcha-
response=03AOLTBLTgQyVi37Vbvg9KMIbXxO2NGfn8wJ85Euh6tViiGx5Kgc-
WUp29qtWk8j6oDgGiuryxdMO8hahCJWhX_10gj5FewUqScSxyBuWifozz40tCjG4NjJJu2JU54J4vh2VtZdvvQWunxGxYaADr7qwtA3AK8wPtOiysLVd8ilh14Se5XEIleX1QFRyC2Nvw1ZVJFiYvTqPWIpB6UXROyTVAXMs4H3EbfuEPIuZwBFY3ma0fr8DdMNFscRiHwulszN-
i7OB6CJtcL6Ir6358s0GGr5SDoX9SmHvHFSlkuEGumj7UhqhmjoHdkkaJ70zHHGI9z800erOaF0IbKAb8GptqrFboH8u1j2dynR1McKYFijqU67RM9Sg-
aYq2V02m1aJ7b2aflgJa


Am Dienstag, 12. März 2019, 18:35:40 CET schrieb Daniele Ricci:
> Did I lose the email by Wiktor? Or did he replied to you only?
> 
> On Tue, 12 Mar 2019, 18:19 Evgeny,  wrote:
> > On Tue, Mar 12, 2019 at 8:17 PM, Evgeny  wrote:
> > > Yeah, my protoXEP allows for instant certificate issuance without
> > > challenges [1]
> > 
> > Oops, forgot the link:
> > http://upload.zinid.ru/xep-eax-cir.html#cert-issuance
> > 
> > ___
> > 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] EAX

[Evgeny]

On Tue, Mar 12, 2019 at 8:35 PM, Daniele Ricci 
 wrote:

Did I lose the email by Wiktor? Or did he replied to you only?


https://mail.jabber.org/pipermail/standards/2019-March/035859.html

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

Re: [Standards] EAX

[Daniele Ricci]

Did I lose the email by Wiktor? Or did he replied to you only?

On Tue, 12 Mar 2019, 18:19 Evgeny,  wrote:

> On Tue, Mar 12, 2019 at 8:17 PM, Evgeny  wrote:
> > Yeah, my protoXEP allows for instant certificate issuance without
> > challenges [1]
>
> Oops, forgot the link:
> http://upload.zinid.ru/xep-eax-cir.html#cert-issuance
>
> ___
> 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] EAX

[Evgeny]

On Tue, Mar 12, 2019 at 8:17 PM, Evgeny  wrote:
Yeah, my protoXEP allows for instant certificate issuance without 
challenges [1]


Oops, forgot the link: 
http://upload.zinid.ru/xep-eax-cir.html#cert-issuance


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

Re: [Standards] EAX

[Evgeny]

On Tue, Mar 12, 2019 at 2:33 PM, Wiktor Kwapisiewicz 
 wrote:
Issuing this certificates can also be automated, just like certbot 
does for Let's Encrypt. This would work in backwards compatible way, 
so for everyone that don't want to opt-in to this scheme a regular 
captcha would be shown. But for everyone that uses the scheme the 
experience would be better.


Hello, thanks for your input.

Yeah, my protoXEP allows for instant certificate issuance without 
challenges [1]
And we can probably have different kinds of CAs or some X.509 extension 
to indicate how strict the certificate challenge was.
Probably we can have also tokens (as long as they are trusted) or 
something for anonymous messaging too, but I'm not competent in this, 
so cannot comment.


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

Re: [Standards] XEP-0166: Jingle question, calls using explicit resources

[Ненахов Андрей]

вт, 12 мар. 2019 г. в 20:19, Daniel Gultsch :

> Have you seen https://xmpp.org/extensions/xep-0353.html?
>

No,we haven't, but this seems to address the same problem. Thank you, we'll
take a look.

>From the first glance it seems that this might work, but it's not clear why
there needs to be a separate XEP instead of amending 0166 - that one does
not look to be widely implemented.

-- 
Andrew Nenakhov
CEO, Redsolution, Inc.
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0166: Jingle question, calls using explicit resources

[Daniel Gultsch]

Have you seen https://xmpp.org/extensions/xep-0353.html?

On Tue, Mar 12, 2019, 16:00 Ненахов Андрей 
wrote:

> Hi, standards people.
>
> We're in early stage of implementing XEP-0166: Jingle in our iOS client
> (mostly because we *really* want those
>  sweet high-priority
> background notifications), and we ran into a problem:
>
> per XEP-0166, initiator sends iq stanza to full jid:
>
>  id='xs51r0k4'
> to='jul...@capulet.lit/balcony'
> type='set'>
>
> And it is the problem.
>
> 1) This message can't be delivered to some offline iOS devices, because 
> sender does not necessarily know their resources at all
> 2) Initiator should not choose which device will responder use to answer a 
> call.
>
> We're currenlty thinking to use message type stanzas sent to barejid to 
> initiate jingle session, and the XEP should probably be amended to address 
> these two problems.
>
>
> --
> Andrew Nenakhov
> CEO, Redsolution, Inc.
> https://redsolution.com 
> ___
> 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
___

[Standards] XEP-0166: Jingle question, calls using explicit resources

[Ненахов Андрей]

Hi, standards people.

We're in early stage of implementing XEP-0166: Jingle in our iOS client
(mostly because we *really* want those
 sweet high-priority
background notifications), and we ran into a problem:

per XEP-0166, initiator sends iq stanza to full jid:



And it is the problem.

1) This message can't be delivered to some offline iOS devices,
because sender does not necessarily know their resources at all
2) Initiator should not choose which device will responder use to
answer a call.

We're currenlty thinking to use message type stanzas sent to barejid
to initiate jingle session, and the XEP should probably be amended to
address these two problems.


-- 
Andrew Nenakhov
CEO, Redsolution, Inc.
https://redsolution.com 
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] MIX

[Dave Cridland]

Hi all,

I've been writing a quick and dirty implementation of MIX.

So far, I've started with an even quicker and dirtier PubSub, and glued in
the MIX stuff on top. There's no MAM etc yet.

The following are comments I've had so far, in no particular order:

*  is sent to the sender for correlation. This assumes that
messages sent from all the user's clients will have unique message ids -
that's a stronger requirement than RFC 6120 dictates. It feels as though
this could include the original full jid as well - or perhaps even instead
- and might benefit from using the  element already defined
elsewhere.

* Section 7.2 stipulates that archiving of all messages is mandatory - did
you really mean that?

* Section 7.1.2 jumps through several hoops to ensure that joining a MIX
Channel without subscribing to any nodes at all is a legitimate choice. I
think the specification and implementation would be radically simpler if we
didn't allow this - is there a use-case for this I'm missing? Without this,
we can choose to have a "sensible default", or just make it an error.

* I'd dearly love to s/node/stream/ for the nodes within a channel.

* Section 7.1.5 suggests MIX messages should be archived at the server.
This is very different to MUC, where clients always request messages
directly from the MUC. It's a useful model with non-chat and other
non-trivial cases, where the archive might actually be synthesized on
demand from the source of whatever history is. Is there a rationale here?
The existing MUC/MAM model seems to work very well. I imagine this probably
doesn't matter, beyond clients having to guess when they joined a channel
in order to redirect MAM requests.

* The XEP explains that a nickname is not needed, but also says it's needed
for both presence and sending messages - or at least in Section 7.1.4, it
says it's not needed if you don't do either. Does this mean that a
participant without a nickname cannot send messages or presence?

* Old participants never die, they're merely removed from the pubsub node
and require endless searching through MAM, or having all their data copied
to the outgoing messages. MIX has lent toward both those options over its
development, currently leaning toward the latter. Should we just include
the participant element in the outgoing messages, instead of duplicating
its contents? Should we have a all-participants node containing every
participant ever (so a get-item is simple for lookup)? Should MIX messages
include the stable participant id?

* Nobody knows how MAM interacts with PubSub. I think it should store an
archive of the stream of events emitted by the pubsub node: at least item
publication events, and probably retractions. While this is all that's
required to make MIX/MAM work well, I note that numerous other events also
exist, which might be useful eventually.

* Participants always have jids, even when anonymous. It's not wholly clear
to me this is needed - the jids are the same computed ones used in presence
for non-anonymous MIX channels, and are in any case only used in '404 for
private messaging (I think!).

* Having messages come from the channel jid allows for lots of flexibility,
but does mean that in the "classic" chatroom case it's harder for clients
to block participants without blocking the entire chatroom. That said, a
MIX-aware server can help here, and a MIX-unaware server would struggle
more in this case I think, which brings me onto:

* I think MIX can be made to work (albeit less efficiently) without MIX-PAM.

This last point needs a detailed explanation, of course, both in terms of
motivation and design.

Firstly, the motivation here is that currently, MIX needs a substantial
fork-lift upgrade to get deployed. Every entity on the path of MIX needs to
implement, and deploy, some MIX in order to work. The benefit of this is
obvious, of course - it means an efficient, and very solid, design, and
it's certainly where we need to get to. But getting There form Here is
going to be difficult, since who wants to implement MIX in their client if
the servers need to support it, and so on.

By having MIX channel servers able to directly interoperate with MIX
clients even if the home server doesn't support MIX, I think we're able to
accelerate deployment.

The changes needed are:

a) A MIX client needs to determine if its home server supports MIX-PAM. If
it does not, a "Direct Join" is used - which is simply exactly the same
join but sent directly to the MIX with full jids.

b) A MIX channel receiving a direct join implies the client's home server
does not support MIX-PAM. It then uses bare Jids in its Participants items
still, but sends messages addressed to the full jid of such clients.

c) When reconnecting, a MIX client which has performed a direct join in a
previous session may have to leave and rejoin - assuming it cannot maintain
the same resource.

Dave.
___
Standards mailing list
Info: https://mail.jabber

Re: [Standards] EAX

[Wiktor Kwapisiewicz]

Hi Evgeny,

The XEPs definitely are one of the most radical things recently proposed 
so I appreciate the short descriptions.


I've been thinking about use-cases that you've described and at first 
sight the SPIM prevention one seems like a good fit. Personally I don't 
have big problems with it (yet?) but if CAs proposed by you did a small 
number of checks before issuing certificates (such as this [0]) * then 
the certificates could also be used as a ticket indicating that sender 
is not likely to be a spammer.


Currently servers employ their own anti-spam measures, for example 
ejabberd has captchas before messages from strangers are delivered. If 
the sender could transparently provide a certificate and the server 
would validate it then no captcha would be necessary.


Issuing this certificates can also be automated, just like certbot does 
for Let's Encrypt. This would work in backwards compatible way, so for 
everyone that don't want to opt-in to this scheme a regular captcha 
would be shown. But for everyone that uses the scheme the experience 
would be better.


This use case is similar to Privacy Pass [1] that already works for HTTP 
over Tor.


Kind regards,
Wiktor

[0]: 
https://github.com/JabberSPAM/jabber-spam-fighting-manifesto#server-policies


*: and limited certificate creations per domain per given amount of time

[1]: https://blog.cloudflare.com/cloudflare-supports-privacy-pass/

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