Re: [Standards] NEW: XEP-0418 (DNS Queries over XMPP (DoX))

[Florian Schmaus]

On 30.03.19 16:48, Jonas Schäfer (XSF Editor) wrote:
> Version 0.1.0 of XEP-0418 (DNS Queries over XMPP (DoX)) has been
> released.
> 
> 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.
> 
> Changelog:
> Accepted by vote of Council on 2019-03-13. (XEP Editor (jsc))
> 
> URL: https://xmpp.org/extensions/xep-0418.html

Love it. Although I don't have an immediate use case, I could imagine
that one will come up possibly.

§ 4

"If the resolver does not support the dns namespace, it MUST return a
 error:"

I suggest to clarify that this is as per RFC 6120 § 8.5

§ 5

Do only entities acting as DoX resolver announce the feature, or all? I
suggest the former and to state that explicit in the XEP.

"In order for an application to determine whether an entity supports
this protocol, where possible it SHOULD use the dynamic, presence-based
profile of service discovery defined in Entity Capabilities (XEP-0115)
[7]. However, if an application has not received entity capabilities
information from an entity, it SHOULD use explicit service discovery
instead."

I am not a friend of the XEP-0115 hint in such situations. It just adds
additional redundancy and noise. XEP-0030 already has a forward hint to
XEP-0115. There is no need to mention it again. I suggest to remove that
paragraph.

"Support could also be pre-arranged between parties by putting a
resolver at a known JID, in which case the requestor can just start
sending queries to the resolver"

Appears pretty obvious to me and nothing a XEP needs to specify
explicitly. I suggest to remove this sentence too. Nit: Missing dot at
the end of the sentence.

§ 6

Whut? How does this result in a disconnection? I also think it does not
belong into this particular XEP, as it is nothing DoX specific.

§ 7

"…therefore all queries and responses MUST use TLS or equivalent
connection security"

Please remove the 'MUST'. There are valid uses cases to use DoX without
transport security. I would suggest to recommend the usage though. At
least use 'SHOULD' as compromise if you must.

"This mitigates classic amplification attacks for UDP- based DNS."

I don't think this is true (in the case of DoX).

A reference to the DNSSEC RFC(s) would be appropriate.

s/dns/DNS/ (everywhere)

The last paragraph in § 7 is also not really DoX specific and I don't
see what the takeaway for DoX-interested readers would be. I suggest to
remove it.

- Florian



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

Re: [Standards] NEW: XEP-0417 (E2E Authentication in XMPP: Certificate Issuance and Revocation)

[Florian Schmaus]

On 30.03.19 16:48, Jonas Schäfer (XSF Editor) wrote:
> Version 0.1.0 of XEP-0417 (E2E Authentication in XMPP: Certificate
> Issuance and Revocation) has been released.
> 
> 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.
> 
> Changelog:
> Accepted by vote of Council on 2019-03-13. (XEP Editor (jsc))
> 
> URL: https://xmpp.org/extensions/xep-0417.html

Thanks for submitting this zinid.

I am especially interested [1] in the client certificate issuance (§ 6.
of this XEP). I even wrote a straw-man [2] so that zinid and I are able
to compare our ideas and vision. Also please note that with XEP-0257 we
have prior-art.

What immediately got my attention reading this XEP-0417 was the
"optional message response as result of a request IQ pattern" used in §
6. To my knowledge this is a new unique pattern in XEP land. To
illustrate, the XEP currently uses a protocol flow as follows:

CSR: Certificate Signing Requester (typically an XMPP Client)
CS: Certificate Signer (typically an XMPP server)

CSR CS
--- --

IQ request
w/ certificate to sign--->
(Example 8)

 - Begin optional protocol flow -

Message
  <---w/ challenge
  (Example 9)

CSR solves
challenge

- End optional protocol flow

 IQ result
  <---   w/ signed certificate
   (Example 10)


At first glance, this looks similar to what we do in MAM: Deferring the
IQ result until the last intermediate message has arrived. But there is
an important difference here: The final IQ result is triggered as result
of the IQ result *receiving* entity.

I am a little bit worried that this will take a few detours to implement
cleanly and elegant in clients and client libraries. Especially since
this pattern never occurred before.

Instead I suggest the following control flow, which should be straight
forward to implement with the facilities libraries currently provide:

CSR CS
--- --

IQ request
w/ certificate to sign--->
(Example 8)


  IQ result
  <---   either w/ optional challenge
  *or* signed certificate

 - Begin optional protocol flow -
CSR solves
challenge

IQ request
indicating that
CSR believes challenge--->
to be solved
 IQ result
  <---w/ signed certificate

- End optional protocol flow

- Florian

1: https://mail.jabber.org/pipermail/standards/2019-February/035805.html
2: http://geekplace.eu/xeps/xep-ccm2/xep-ccm2.html





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

[Standards] NEW: XEP-0419 (Improving Baseline Security in XMPP)

[XSF Editor]

Version 1.0.0 of XEP-0419 (Improving Baseline Security in XMPP) has
been released.

Abstract:
This document describes a number of concrete and effective mechanisms
for offering significant security enhancements to XMPP, with broad
applicability.

Changelog:
Acceptance as XEP-0419 (XEP Editor (jsc))

URL: https://xmpp.org/extensions/xep-0419.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] Stanza Content Encryption

[Florian Schmaus]

On 01.04.19 11:24, Evgeny wrote:
> On Mon, Apr 1, 2019 at 11:13 AM, Paul Schaub  wrote:
>> There was a ton of
>> interesting discussions around OMEMO and other stuff, as well as some
>> productive coding (and Mate!).
> 
> Not to bash the ProtoXEP itself, but why the community constantly
> discussing OMEMO (and sometimes PGP), when there is ongoing work on MLS
> which will most likely be the standard e2e encryption? You also didn't
> mention MLS in your ProtoXEP at all.

I am not exactly sure what you are suggesting: How can we do better? How
would mentioning MLS help improve anything? How can we focus on MLS in a
ProtoXEP if MLS itself isn't XEP'ed yet?

If you want to help with MLS in XMPP, then please do. I am really
looking forward to it. And I know others too.

- Florian



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

Re: [Standards] Council Minutes 2019-03-20

[Kevin Smith]

On 21 Mar 2019, at 17:22, Tedd Sterr  wrote:
> 3b) Last Call: XEP-0353 (Jingle Message Initiation) - 
> https://xmpp.org/extensions/xep-0353.html
> Link notes that there were comments on this from RalphM's previous team, and 
> Андрей's team too; Dave additionally notes Fippo's contacts.
> Dave is surprised this wasn't already Draft - it's pretty straightforward and 
> is the result of practical experience.
> 
> Dave: +1
> Jonas: +1
> Link: +1
> Georg: [pending]
> Kev: [pending]

+1.

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

Re: [Standards] Council Minutes 2019-03-27

[Kevin Smith]

On 31 Mar 2019, at 00:19, Tedd Sterr  wrote:
> 
> http://logs.xmpp.org/council/2019-03-27?p=h#2019-03-27-237ca0091c8adb57
> 
> Dave is having a catastrophic day, so would be grateful for skipping the 
> meeting this week.
> Jonas and Georg would like to at least get the vote started on the Compliance 
> Suites.
> Georg volunteers to chair - Dave takes up his generous offer.
> 
> 1) Welcome everybody, roll call!
> Present: Georg, Jonas, Link
> Distracted: Dave
> Apologies: Kev
> 
> 2) Agenda Bashing
> Georg has XEP-0412 (XMPP Compliance Suites 2019) and Automatic Trust Transfer 
> (ATT).
> Jonas notes that there is an open PR.
> 
> 3a) Advance to Draft: XEP-0412 XMPP (Compliance Suites 2019) - 
> https://xmpp.org/extensions/xep-0412.html
> Jonas: +1
> Link: +1
> Georg: +1
> Dave: [on-list] (wonder if we should consider a last call once more given the 
> change of author)
> Kev: [pending]

-0. I’m still of the opinion that our current model of Compliance Suites that 
we update annually, with lots of noise and time, is unhelpful but won’t block 
progress.

> 3b) Proposed XMPP Extension: Automatic Trust Transfer (ATT) - 
> https://xmpp.org/extensions/inbox/automatic-trust-transfer.html
> Link: [on-list]
> Jonas: [on-list]
> Dave: [on-list]
> Georg: [on-list]
> Kev: [pending]

There’s weirdness here. 

It’s not clear to me what’s being bought by using a URI for the trust message 
format, and that URI seems to be OMEMO-specific, although OMEMO is probably not 
the long-term future, so some genericity seems appropriate here.

 It talks about Devices with authentication, but until I reached section 6 I 
was struggling to understand if this is meant to be a user’s own devices, or 
any device in the graph - I think this would benefit from mentioning much 
earlier (or in a way that was clearer to idiots like me). 

I think the MUSTs on trusting anything sent to you from an authenticated device 
is wrong here - I might have verified that Dave is Dave, but that’s a long way 
from saying that I trust Dave to verify that Cath is Cath (this seems to be an 
authc/authz mismatch issue - I may authenticate Dave, but I don’t necessarily 
authorise him to perform authentication for me), and I very much don’t trust 
Dave to authenticate my new devices for me (I might have multiple identities, 
and ‘own device’ is likely to start breaking down here) - and revoking keys 
here is much worse. 

It says “authenticate a key” and things like it frequently when I think it 
means “treat the key as authenticated” or somesuch. 

There’s a fun amplification attack here, which probably needs mentioning.

"A client MUST save the information of a trust message until the key of the 
device which sent the trust message is authenticated, so that the key can then 
be authenticated or revoked” - That seems well-intentioned but open to abuse 
from malicious users. There are also fun race conditions - you can easily send 
an approval, then revoke the key you sent the approval to, then revoke the key 
you approved, and then log in the device to which you sent it, leaving dangling 
approvals that then get added back into the graph. Indeed, on a large graph, 
it’s easy to end up with revoked keys getting added back in just because of 
transmission latency (which includes waiting for devices to come online).

" If it is not possible to authenticate a key before encrypting with it but it 
is desired to communicate with the key's device, it is RECOMMENDED to blindly 
trust new keys until the first authentication has been made.” Is 
well-intentioned, but I think needs careful wording to avoid just making TOFU 
the default. Plus, once that new key is blindly trusted, someone’s going to 
send it out over ATT.

And the minor issue that after reading it I don’t immediately understand what 
the protocol here is.

-1 - I don’t think it’s possible to implement from the spec as-is, but more 
crucially I think that there are fundamental security considerations here that 
are missing (or aren’t obvious enough that I understood them on first reading), 
and given OMEMO’s history of getting picked up and deployed early I think 
publishing this right now would be ill-advised


> 3c) PR #764 - XEP-0308: Clarify correcting a message multiple times 
> -https://github.com/xsf/xeps/pull/764
> Link thinks this will break existing clients which correct based on the 
> previous ID (rather than the original, as this PR does) - Jonas believes it 
> should.
> 
> Jonas: +1 (it's the obvious reading of the XEP in my opinion, though others 
> may have their own 'obvious readings'; we should pick an official obvious 
> reading)
> Dave: [on-list]
> Georg: -1 (the XEP is in dire need of clarification, but it's more logical to 
> correct the last message, not the first, e.g. when fetching partial MUC 
> history)
> Link: 0 (will break clients, but so will the other way, even if that seems 
> more logical to me)
> Kev: [pending]

+1. And whether Georg is right about it being more logical 

Re: [Standards] NEW: XEP-0418 (DNS Queries over XMPP (DoX))

[Tedd Sterr]

RFC 4648 [1] defines two encodings for base 64:

§ 4. Base 64 Encoding: the familiar [A-Za-z0-9+/]; and
§ 5. Base 64 Encoding with URL and Filename Safe Alphabet: [A-Za-z0-9-_]

For the latter it says:

> This encoding may be referred to as "base64url".  This encoding
> should not be regarded as the same as the "base64" encoding and
> should not be referred to as only "base64".  Unless clarified
> otherwise, "base64" refers to the base 64 in the previous section.

So "base64" should always refer to the classic version, and "base64url" to the 
'safe' version.
Of course, whether people are aware and stick to this is another matter; though 
I'd like to think it should usually be obvious which version is required.


[1] https://www.rfc-editor.org/rfc/rfc4648.txt


From: Standards  on behalf of Sam Whited 

Sent: 01 April 2019 15:36
To: standards@xmpp.org
Subject: Re: [Standards] NEW: XEP-0418 (DNS Queries over XMPP (DoX))

On Sat, Mar 30, 2019, at 15:51, Jonas Schäfer wrote:
> Version 0.1.0 of XEP-0418 (DNS Queries over XMPP (DoX)) has been
> released.

The DNS request and response are encoded like so:

> The body MUST be encoded with base64 RFC 4648 [5]. Padding characters
> for base64 MUST NOT be included.

But there's no mention off what alphabet is used. I'm assuming this is
the standard one (as opposed to the URL/filename safe one), but I always
feel like this should be explicitly stated when base64 is used.

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

Re: [Standards] NEW: XEP-0418 (DNS Queries over XMPP (DoX))

[Sam Whited]

On Sat, Mar 30, 2019, at 15:51, Jonas Schäfer wrote:
> Version 0.1.0 of XEP-0418 (DNS Queries over XMPP (DoX)) has been
> released.

The DNS request and response are encoded like so:

> The body MUST be encoded with base64 RFC 4648 [5]. Padding characters
> for base64 MUST NOT be included.

But there's no mention off what alphabet is used. I'm assuming this is
the standard one (as opposed to the URL/filename safe one), but I always
feel like this should be explicitly stated when base64 is used.

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

Re: [Standards] Stanza Content Encryption

[Philipp Hörist]

Hi,

> Within the IEEE IoT Harmonization effort, there is a mechanism to
E2E-encrypt stanzas in XMPP:

> https://gitlab.com/IEEE-SA/XMPPI/IoT/blob/master/E2E.md


This seems targeted specifically to IoT which seem to have different needs


Just two points from this document that i see completely fail for the IM
use case


1. Exchanging Public Keys with presence

2. Encrypting all nodes inside message and iq


Stuff that we need to decide has not much to do with the encryption, like


1. What nodes should *not* be encrypted, which should be encrypted

2. What should i do if i find nodes outside of the encrypted container and
inside of the encrypted payload (after decrypting) which wins?

3. Maybe a blacklist/whitelist of nodes for 2.


regards

Philipp



Am Mo., 1. Apr. 2019 um 13:53 Uhr schrieb Dave Cridland :

> Why is the IEEE working on this? Surely it would be considerably more
> productive just to ask the XSF (or even the IETF, I can see arguments for
> both) about the problem?
>
> On Mon, 1 Apr 2019 at 10:51, Peter Waher  wrote:
>
>> Hello Paul, and those in the community interested in end-to-end
>> encryption of stanzas.
>>
>>
>>
>> Within the IEEE IoT Harmonization effort, there is a mechanism to
>> E2E-encrypt stanzas in XMPP:
>>
>> https://gitlab.com/IEEE-SA/XMPPI/IoT/blob/master/E2E.md
>>
>>
>>
>> Site for the IEEE IoT Harmonization project:
>>
>> https://gitlab.com/IEEE-SA/XMPPI/IoT
>>
>>
>>
>> Best regards,
>>
>> Peter Waher
>>
>>
>>
>> --
>>
>> > Hi everyone!
>> >
>> > The Sprint in Berlin was great and it was huge fun meeting so many
>> > developers (and users as well!) in person. There was a ton of
>> > interesting discussions around OMEMO and other stuff, as well as some
>> > productive coding (and Mate!).
>> >
>> > I took the opportunity to once again start a discussion around partial
>> > stanza encryption. The results have been collected in the XMPP wiki:
>> >
>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.xmpp.org%2Fweb%2FStanza_encryptiondata=02%>
>>
>> 7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065421995310sdata=YqVBLurjKA1xIqjIMqKweWXhm6hhk%2F7cdLfpwkiyOjg%3Dreserved=0
>> 
>> >
>> > The ultimate goal is to create a ProtoXEP along with some experimental
>> > implementations, so we can finally start to gather some experience on
>> > this unexplored topic. I know there be dragons and we should carefully
>> > think about rules to prevent evil things from happening, but we also
>> > have to get started, as I think this topic has been postponed for all
>> > too long.
>> >
>> > The specification is worked on on Github and a rendered version can be
>> > found below (this is all what I came up with while on my train home).
>> > The purpose of this mail is to get some first feedback and make people
>> > aware about the work, so they can get involved in the process :)
>> >
>> >
>> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvanitasvitae%2Fflowdalic-xeps%2Ftree%2Fscedata=02%7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065421995310sdata=T61uPbN2631En4SqdiDMW2Gwk5pfgrCxZXFmFxHpt%2Bg%3Dreserved=0
>>
>> https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgeekplace.eu%2Fxeps%2Fxep-sce%2Fxep-sce.htmldata=02%7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065422005321sdata=3BvePHpJPZICLrqxlfiRW7sCL0EwLRov%2FEc6l5i%2Bkic%3Dreserved=0
>> >
>> > I also created a small MUC on the topic, although the address is not
>> > final, as I may move the conversation to a more stable server (mine is
>> > hosted behind dyndns, so Schroedingers Chat might kick in :/).
>> >
>> > xmpp:s...@conference.jabberhead.tk?join
>> >
>> > Happy Hacking!
>>
>> ___
>> 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 mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] Stanza Content Encryption

[Dave Cridland]

Why is the IEEE working on this? Surely it would be considerably more
productive just to ask the XSF (or even the IETF, I can see arguments for
both) about the problem?

On Mon, 1 Apr 2019 at 10:51, Peter Waher  wrote:

> Hello Paul, and those in the community interested in end-to-end encryption
> of stanzas.
>
>
>
> Within the IEEE IoT Harmonization effort, there is a mechanism to
> E2E-encrypt stanzas in XMPP:
>
> https://gitlab.com/IEEE-SA/XMPPI/IoT/blob/master/E2E.md
>
>
>
> Site for the IEEE IoT Harmonization project:
>
> https://gitlab.com/IEEE-SA/XMPPI/IoT
>
>
>
> Best regards,
>
> Peter Waher
>
>
>
> --
>
> > Hi everyone!
> >
> > The Sprint in Berlin was great and it was huge fun meeting so many
> > developers (and users as well!) in person. There was a ton of
> > interesting discussions around OMEMO and other stuff, as well as some
> > productive coding (and Mate!).
> >
> > I took the opportunity to once again start a discussion around partial
> > stanza encryption. The results have been collected in the XMPP wiki:
> >
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.xmpp.org%2Fweb%2FStanza_encryptiondata=02%>
>
> 7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065421995310sdata=YqVBLurjKA1xIqjIMqKweWXhm6hhk%2F7cdLfpwkiyOjg%3Dreserved=0
> 
> >
> > The ultimate goal is to create a ProtoXEP along with some experimental
> > implementations, so we can finally start to gather some experience on
> > this unexplored topic. I know there be dragons and we should carefully
> > think about rules to prevent evil things from happening, but we also
> > have to get started, as I think this topic has been postponed for all
> > too long.
> >
> > The specification is worked on on Github and a rendered version can be
> > found below (this is all what I came up with while on my train home).
> > The purpose of this mail is to get some first feedback and make people
> > aware about the work, so they can get involved in the process :)
> >
> >
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvanitasvitae%2Fflowdalic-xeps%2Ftree%2Fscedata=02%7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065421995310sdata=T61uPbN2631En4SqdiDMW2Gwk5pfgrCxZXFmFxHpt%2Bg%3Dreserved=0
>
> https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgeekplace.eu%2Fxeps%2Fxep-sce%2Fxep-sce.htmldata=02%7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065422005321sdata=3BvePHpJPZICLrqxlfiRW7sCL0EwLRov%2FEc6l5i%2Bkic%3Dreserved=0
> >
> > I also created a small MUC on the topic, although the address is not
> > final, as I may move the conversation to a more stable server (mine is
> > hosted behind dyndns, so Schroedingers Chat might kick in :/).
> >
> > xmpp:s...@conference.jabberhead.tk?join
> >
> > Happy Hacking!
>
> ___
> 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 Content Encryption

[Peter Waher]

Hello Paul, and those in the community interested in end-to-end encryption of 
stanzas.

Within the IEEE IoT Harmonization effort, there is a mechanism to E2E-encrypt 
stanzas in XMPP:
https://gitlab.com/IEEE-SA/XMPPI/IoT/blob/master/E2E.md

Site for the IEEE IoT Harmonization project:
https://gitlab.com/IEEE-SA/XMPPI/IoT

Best regards,
Peter Waher

--

> Hi everyone!
>
> The Sprint in Berlin was great and it was huge fun meeting so many
> developers (and users as well!) in person. There was a ton of
> interesting discussions around OMEMO and other stuff, as well as some
> productive coding (and Mate!).
>
> I took the opportunity to once again start a discussion around partial
> stanza encryption. The results have been collected in the XMPP wiki:
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.xmpp.org%2Fweb%2FStanza_encryptiondata=02%>
>  
> 7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065421995310sdata=YqVBLurjKA1xIqjIMqKweWXhm6hhk%2F7cdLfpwkiyOjg%3Dreserved=0
>
> The ultimate goal is to create a ProtoXEP along with some experimental
> implementations, so we can finally start to gather some experience on
> this unexplored topic. I know there be dragons and we should carefully
> think about rules to prevent evil things from happening, but we also
> have to get started, as I think this topic has been postponed for all
> too long.
>
> The specification is worked on on Github and a rendered version can be
> found below (this is all what I came up with while on my train home).
> The purpose of this mail is to get some first feedback and make people
> aware about the work, so they can get involved in the process :)
>
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fvanitasvitae%2Fflowdalic-xeps%2Ftree%2Fscedata=02%7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065421995310sdata=T61uPbN2631En4SqdiDMW2Gwk5pfgrCxZXFmFxHpt%2Bg%3Dreserved=0
https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgeekplace.eu%2Fxeps%2Fxep-sce%2Fxep-sce.htmldata=02%7C01%7C%7Cd32bc798ae25486bb0c008d6b681ae6f%7C84df9e7fe9f640afb435%7C1%7C0%7C636897065422005321sdata=3BvePHpJPZICLrqxlfiRW7sCL0EwLRov%2FEc6l5i%2Bkic%3Dreserved=0
>
> I also created a small MUC on the topic, although the address is not
> final, as I may move the conversation to a more stable server (mine is
> hosted behind dyndns, so Schroedingers Chat might kick in :/).
>
> xmpp:s...@conference.jabberhead.tk?join
>
> Happy Hacking!

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

Re: [Standards] Stanza Content Encryption

[Daniel Gultsch]

Am Mo., 1. Apr. 2019 um 09:26 Uhr schrieb Evgeny :
>
> On Mon, Apr 1, 2019 at 11:13 AM, Paul Schaub 
> wrote:
> > There was a ton of
> > interesting discussions around OMEMO and other stuff, as well as some
> > productive coding (and Mate!).
>
> Not to bash the ProtoXEP itself, but why the community constantly
> discussing OMEMO (and sometimes PGP), when there is ongoing work on MLS
> which will most likely be the standard e2e encryption? You also didn't
> mention MLS in your ProtoXEP at all.

Aside from all the justified criticism of OMEMO it is currently the
best option for the casual user who uses a public server. 27 is still
a mess to set up; OTR is complete garbage and MLS is simply not
available right now. Also we have successfully pushed OMEMO into a
fairly high number of clients; it would be unfair to users and
developers alike to just drop it. That doesn’t mean we can’t
simultaneously explore other options.

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

Re: [Standards] Stanza Content Encryption

[Paul Schaub]

Hi!
Well, MLS is not even a thing yet. The slrint made it very clear, that OMEMO is 
a thing which people actually use. Of the 20 people that participated in the 
sprint, at least 15 were working on OMEMO related projects.

The ProtoXEP is intended to be used with any encryption algorithm and that also 
includes MLS. Still there is no reason to explicitly mention it :)

Am 1. April 2019 11:24:49 MESZ schrieb Evgeny :
>On Mon, Apr 1, 2019 at 11:13 AM, Paul Schaub  
>wrote:
>> There was a ton of
>> interesting discussions around OMEMO and other stuff, as well as some
>> productive coding (and Mate!).
>
>Not to bash the ProtoXEP itself, but why the community constantly 
>discussing OMEMO (and sometimes PGP), when there is ongoing work on MLS
>
>which will most likely be the standard e2e encryption? You also didn't 
>mention MLS in your ProtoXEP at all.
>
>___
>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 Content Encryption

[Evgeny]

On Mon, Apr 1, 2019 at 11:13 AM, Paul Schaub  
wrote:

There was a ton of
interesting discussions around OMEMO and other stuff, as well as some
productive coding (and Mate!).


Not to bash the ProtoXEP itself, but why the community constantly 
discussing OMEMO (and sometimes PGP), when there is ongoing work on MLS 
which will most likely be the standard e2e encryption? You also didn't 
mention MLS in your ProtoXEP at all.


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

Re: [Standards] MIX Implementation (Prosody module)

[Evgeny]

On Mon, Apr 1, 2019 at 12:03 PM, Tedd Sterr  
wrote:

somewhat working MIX implementation!


Apr 1 :/

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

Re: [Standards] MIX Implementation (Prosody module)

[Guus der Kinderen]

Your cat has skills!

On Mon, 1 Apr 2019 at 11:04, Tedd Sterr  wrote:

> I wasn't at the Berlin sprint, so I held my own mini-sprint - at home,
> pair-programming with my cat - which mainly involved me coding and her not
> paying any attention. After an extended weekend, too much caffeine, and
> meals consisting mainly of unhealthy snacks, I present to you a somewhat
> working MIX implementation!
>
> https://bitbucket.org/mrtedd/mixosaurus/
>
> Please note: this is unfinished and there will be bugs, but it works well
> enough for testing.
>
> ___
> 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] MIX Implementation (Prosody module)

[Tedd Sterr]

I wasn't at the Berlin sprint, so I held my own mini-sprint - at home, 
pair-programming with my cat - which mainly involved me coding and her not 
paying any attention. After an extended weekend, too much caffeine, and meals 
consisting mainly of unhealthy snacks, I present to you a somewhat working MIX 
implementation!

https://bitbucket.org/mrtedd/mixosaurus/

Please note: this is unfinished and there will be bugs, but it works well 
enough for testing.

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

[Standards] Stanza Content Encryption

[Paul Schaub]

Hi everyone!

The Sprint in Berlin was great and it was huge fun meeting so many
developers (and users as well!) in person. There was a ton of
interesting discussions around OMEMO and other stuff, as well as some
productive coding (and Mate!).

I took the opportunity to once again start a discussion around partial
stanza encryption. The results have been collected in the XMPP wiki:
https://wiki.xmpp.org/web/Stanza_encryption

The ultimate goal is to create a ProtoXEP along with some experimental
implementations, so we can finally start to gather some experience on
this unexplored topic. I know there be dragons and we should carefully
think about rules to prevent evil things from happening, but we also
have to get started, as I think this topic has been postponed for all
too long.

The specification is worked on on Github and a rendered version can be
found below (this is all what I came up with while on my train home).
The purpose of this mail is to get some first feedback and make people
aware about the work, so they can get involved in the process :)

https://github.com/vanitasvitae/flowdalic-xeps/tree/sce
http://geekplace.eu/xeps/xep-sce/xep-sce.html

I also created a small MUC on the topic, although the address is not
final, as I may move the conversation to a more stable server (mine is
hosted behind dyndns, so Schroedingers Chat might kick in :/).

xmpp:s...@conference.jabberhead.tk?join

Happy Hacking!



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