Re: [Standards] UPDATED: XEP-0278 (Jingle Relay Nodes)

2017-09-19 Thread Peter Saint-Andre 
Hey Thiago, is this protocol still in use? I've always liked it. ;-)

On 9/15/17 11:39 AM, Jonas Wielicki (XSF Editor) wrote:
> Version 0.2 of XEP-0278 (Jingle Relay Nodes) has been released.
> 
> Abstract:
> This documents specifies how Jingle Clients can interact with Jingle
> Relay Nodes Services and how XMPP entities can provide, search and
> list available Jingle Relay Nodes.
> 
> Changelog:
> Added TURN Credentials Service Support. (tc)
> 
> URL: https://xmpp.org/extensions/xep-0278.html
> ___
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> ___
> 




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

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

2017-09-19 Thread Sam Whited 
On Tue, Sep 19, 2017, at 11:15, Jonas Wielicki wrote:
> * Do we need to interact with some registry to get xmpps-server and
> xmpps-
> client SRV record service names registered? From my understanding, SRV
> records 
> can use the names as assigned in [3] or "locally defined" (whatever that 
> means!). Does what we do classify as "locally defined" and is sufficient?
> If 
> not, we should probably get xmpps-server / xmpps-client registered
> somewhere.

IANA has been contacted and the designated expert has said he's fine
with the registration from the XEP. Presumably he just hasn't gotten
around to publishing it yet.

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

Re: [Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

2017-09-19 Thread Jonas Wielicki 
Now with my client developer hat on.

> 1. What software has XEP-0368 implemented?

I implemented XEP-0368 support in aioxmpp [1] (which is under LGPLv3 license).

> 2. Have developers experienced any problems with the protocol as defined
> in XEP-0368?

I did not have outstanding issues (the ones I had have been clarified since 
then). I did not implement ALPN support though (which is a SHOULD in the 
spec), because I didn’t have a chance to look into how to do that yet.

> 3. Is the text of XEP-0368 clear and unambiguous? 

I think so.

> Are more examples
> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have
> developers found the text confusing at all? 

Two final remarks:

* I find that the ALPN protocol ID registration still hasn’t gotten through to 
the official IANA registry [2].

* Do we need to interact with some registry to get xmpps-server and xmpps-
client SRV record service names registered? From my understanding, SRV records 
can use the names as assigned in [3] or "locally defined" (whatever that 
means!). Does what we do classify as "locally defined" and is sufficient? If 
not, we should probably get xmpps-server / xmpps-client registered somewhere.


Otherwise I find the XEP short and precise, understable, and easy to 
implement.


kind regards,
Jonas


   [1]: https://github.com/horazont/aioxmpp/blob/
97b34721585e2f761195ce1df5b2fc7dd42d3ef9/aioxmpp/node.py#L106
   [2]: 
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids
   [3]: 
https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

[Standards] Call for Experience for XEP-0368: SRV records for XMPP over TLS

2017-09-19 Thread Jonas Wielicki 
Dear list,

With my XEP Editor hat on, we’d like to issue a Call for Experience for 
XEP-0368. This is the step taken before proposing advancement of a XEP to 
Final status to Council.


During the Call for Experience, please answer the following questions:

1. What software has XEP-0368 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.

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

3. Is the text of XEP-0368 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.

If you have any comments about advancing XEP-0368 from Draft to Final,
please provide them by the close of business on Tuesday, October 3rd, 
2017. 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://www.xmpp.org/extensions/xep-0368.html

Please send all feedback to the standards@xmpp.org discussion list.

Thanks!

Jonas

P.S.: Procedural note: I’m not entirely clear on what is allowed to trigger a 
CFE (I don’t think that’s spelled out in XEP-0001). In this specific case, the 
author asked for it.

signature.asc
Description: This is a digitally signed message part.
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XMPP Meetup during T-DOSE in Eindhoven (NL) in November

2017-09-19 Thread Guus der Kinderen 
Hi all,

A quick update on T-DOSE 2017.

As the amount of responses to Tim's suggestion to have a meetup was very
low, we've opted to not follow-up on the offer of a dedicated room for
XSF/XMPP. We did, however, request a booth. If you're interested in joining
us there, please let us know (either here, or at
https://wiki.xmpp.org/web/T-DOSE_2017 )

Regards,

  Guus

On 22 August 2017 at 09:59, Timothée Jaussoin  wrote:

> Hello everyone,
>
> I've created a page on the Wiki for the project
> https://wiki.xmpp.org/web/T-DOSE_2017.
> If you are interested to come, do a conference, a XMPP meetup or something
> related, please put it on this page :)
>
> Regards,
>
> Timothée
>
> Le lundi 31 juillet 2017 à 12:18 +0200, Guus der Kinderen a écrit :
> > Hi Timothée,
> >
> > Thanks for taking the time to organize this! I'd certainly be interested
> in attending.
> >
> > As for XSF support: what exactly do you need? This year, the XSF created
> the SCAM (somethingsometing, Conferences And Meetups)
> > workgroup (of which I may or may not be a part). I am not aware of any
> activity of that workgroup other than its inception. This
> > event might be a good first event to get SCAM-things going though.
> >
> > Regards,
> >
> >   Guus
> >
> > On 30 July 2017 at 22:50, Timothée Jaussoin  wrote:
> > > Hi everyone,
> > >
> > > I'm currently in contact with an organizer of the T-DOSE event. For
> those that don't know T-DOSE.
> > >
> > > T-DOSE is a free and yearly event held in The Netherlands to
> promote use and development of Open Source Software. During this
> > > event
> > > Open Source projects, developers and visitors can exchange ideas
> and knowledge. This years event will be held at the Fontys
> > > University of Applied Science in Eindhoven on November 18 and 19.
> > >
> > > More info here http://www.t-dose.org/.
> > >
> > > I think that it could be a nice opportunity to meet-up there and maybe
> have conferences to promote the XMPP protocol :)
> > > The organizers told me that they have classrooms available where we
> could talk and that they are open for conferences proposal
> > > (deadline September 30).
> > >
> > > For those that are interested to take part of it and help with the
> organization do not hesitate to answer that mail.
> > > I don't have a clear idea how we organize our participation into such
> event in the XSF, should I create a Wiki page? Is it possible
> > > to
> > > put it in the agenda for the next meeting?
> > >
> > > On my side I can help with the communication with the T-DOSE team, I'm
> also interested to propose a conference (around
> > > Movim/social-
> > > networking on XMPP…) and participate in discussion if we meet-up to
> talk about the current XEP in progress.
> > >
> > > Kind regards,
> > >
> > > Timothée Jaussoin
> > > ___
> > > 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
> ___
>
___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0384 OMEMO questions

2017-09-19 Thread Florian Schmaus 
On 19.09.2017 12:35, Remko Tronçon wrote:
> 
> The original authors of the XEP worked on a follow up version [1] which
> put the wire format into the XEP
> 
> 
> This follow-up version is in its current state even more underspecified
> than the libsignal one (for example, it's impossible to know how to
> authenticate the sent payload IIRC). 

If that's the case then lets improve it.

> and was based (mostly) on the Signal
> specification, which is a open standard [2].
> 
> 
> Signal's wire format is not an open standard AFAIK. For example, the
> first byte of a key is used to define the key format, which is only
> hinted in some of the specs.

Possibly, but that is exactly why people wanted to put the wire format
into the XEP while reusing the basic ratchet mechanism that is already
widely used by existing OMEMO implementations.

> could reimplement everything from scratch (if they want)
> 
> 
> 

I don't remember arguments that XEdDSA could not be reimplemented. Any
well specified open standard can be implemented. If you don't feel
comfortable implementing it yourself, and are not able to use an
existing library, then I'm sure you would find a skilled programmer that
you can pay to implement it.

The arguments I've heard against XEdDSA where something like 1. "It's
not widespread" and 2. "There is no permissive license library". Both
are IMHO not worth the trade-off to switch to something else, because 1.
it is widely used, and 2. if you aren't happy with the existing library
ecosystem, then you are free to create an new one (you probably have to
put some money on the table). But OMEMO, using XEdDSA, is obviously no
problem for open source projects, otherwise we wouldn't have nearly half
a dozen implementations finished and many more to come [1].

- Florian

1: https://omemo.top/




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

Re: [Standards] XEP-0384 OMEMO questions

2017-09-19 Thread Remko Tronçon 
> The original authors of the XEP worked on a follow up version [1] which
> put the wire format into the XEP


This follow-up version is in its current state even more underspecified
than the libsignal one (for example, it's impossible to know how to
authenticate the sent payload IIRC).


> and was based (mostly) on the Signal
> specification, which is a open standard [2].


Signal's wire format is not an open standard AFAIK. For example, the first
byte of a key is used to define the key format, which is only hinted in
some of the specs.

could reimplement everything from scratch (if they want)




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

Re: [Standards] XEP-0384 OMEMO questions

2017-09-19 Thread Florian Schmaus 
On 19.09.2017 11:37, Dave Cridland wrote:
> On 19 September 2017 at 09:21, Klaus Herberth  wrote:
>>> Hi Klaus,
>> Hi Andrey,
>>
>>> What do you mean by "libsignal"? There are at least 4(+1) libraries:
>> With libsignal I referred to your linked implementations of WhisperSystems.
>>
>>> Note, javascript favor is already available.
>> I know, but it is GPL and this doesn't work for everyone.
>>
>>> BTW, why is it terrible?
>> It's terrible, because the wire format of those implementations aren't
>> documented (as far as I know) and therefore it's quite hard to implement
>> such protocol by your own. I think a protocol should be like an Internet
>> Standard defined in RFC1310:
>>
>>  "In general, an Internet Standard is a specification that is stable
>>   and well-understood, is technically competent, has multiple,
>>   independent, and interoperable implementations with operational
>>   experience, enjoys significant public support, and is recognizably
>>   useful in some or all parts of the Internet."
>>
>> I think "multiple independent and interoperable implementations" are
>> currently missing for the "signal protocol". If we would have some kind
>> of documentation for the wire format and a clear hint in the XEP that
>> libsignal is needed it would be a great help for everyone who wants to
>> implement this XEP.
>>
> 
> I entirely and unreservedly agree with you.
> 
> For what its worth, the XMPP Council originally rejected this XEP
> because it was reliant on a single library; while we were assured that
> this was not the case anymore, and anyone could easily (I believe the
> word "trivially" was used multiple times) implement a fully
> independent implementation and have it interoperate, you are sadly
> proving that this is not the case.

You are only telling half of the story.

The original authors of the XEP worked on a follow up version [1] which
put the wire format into the XEP and was based (mostly) on the Signal
specification, which is a open standard [2]. The existing OMEMO
implementations could trivially upgrade to what is specified in [1], and
new implementations, like the one Klaus tries to write, could
reimplement everything from scratch (if they want), since the ultimate
goal of [1] was it to have all parts openly and well specified. Or, of
course, new implementations could reuse the existing
Axolotl/Signal/OMEMO ecosystem of libraries.

Sadly that change was torpedoed by a small group (including you).

- Florian

1: https://github.com/xsf/xeps/pull/460
2: https://signal.org/docs/



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

Re: [Standards] XEP-0384 OMEMO questions

2017-09-19 Thread Dave Cridland 
On 19 September 2017 at 09:21, Klaus Herberth  wrote:
>> Hi Klaus,
> Hi Andrey,
>
>
>> What do you mean by "libsignal"? There are at least 4(+1) libraries:
> With libsignal I referred to your linked implementations of WhisperSystems.
>
>> Note, javascript favor is already available.
> I know, but it is GPL and this doesn't work for everyone.
>
>> BTW, why is it terrible?
> It's terrible, because the wire format of those implementations aren't
> documented (as far as I know) and therefore it's quite hard to implement
> such protocol by your own. I think a protocol should be like an Internet
> Standard defined in RFC1310:
>
>  "In general, an Internet Standard is a specification that is stable
>   and well-understood, is technically competent, has multiple,
>   independent, and interoperable implementations with operational
>   experience, enjoys significant public support, and is recognizably
>   useful in some or all parts of the Internet."
>
> I think "multiple independent and interoperable implementations" are
> currently missing for the "signal protocol". If we would have some kind
> of documentation for the wire format and a clear hint in the XEP that
> libsignal is needed it would be a great help for everyone who wants to
> implement this XEP.
>

I entirely and unreservedly agree with you.

For what its worth, the XMPP Council originally rejected this XEP
because it was reliant on a single library; while we were assured that
this was not the case anymore, and anyone could easily (I believe the
word "trivially" was used multiple times) implement a fully
independent implementation and have it interoperate, you are sadly
proving that this is not the case.

>> It's not that uncommon a program can be compiled only with openssl
>> (and even not with the latest version).
> Please correct me if I'm wrong, but everything in openssl is documented
> somewhere. There is no magic happening inside this library and therefore
> the comparison doesn't work. Also openssl is under Apache License which
> makes it a lot easier to use it in combination with other software.

As far as I am aware, OpenSSL is based entirely on well-known and
fully documented protocols and algorithms. Even the API has some
documentation, increasingly accurate as well these days. There are
numerous TLS libraries, and numerous implementations of the
cryptographic primitives used by OpenSSL. I, like you, have no idea
why anyone would consider this a useful comparison.

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

Re: [Standards] XEP-0384 OMEMO questions

2017-09-19 Thread Klaus Herberth 
> Hi Klaus, 
Hi Andrey,


> What do you mean by "libsignal"? There are at least 4(+1) libraries: 
With libsignal I referred to your linked implementations of WhisperSystems.

> Note, javascript favor is already available. 
I know, but it is GPL and this doesn't work for everyone.

> BTW, why is it terrible?
It's terrible, because the wire format of those implementations aren't
documented (as far as I know) and therefore it's quite hard to implement
such protocol by your own. I think a protocol should be like an Internet
Standard defined in RFC1310:

 "In general, an Internet Standard is a specification that is stable
  and well-understood, is technically competent, has multiple,
  independent, and interoperable implementations with operational
  experience, enjoys significant public support, and is recognizably
  useful in some or all parts of the Internet."

I think "multiple independent and interoperable implementations" are
currently missing for the "signal protocol". If we would have some kind
of documentation for the wire format and a clear hint in the XEP that
libsignal is needed it would be a great help for everyone who wants to
implement this XEP.

> It's not that uncommon a program can be compiled only with openssl
> (and even not with the latest version). 
Please correct me if I'm wrong, but everything in openssl is documented
somewhere. There is no magic happening inside this library and therefore
the comparison doesn't work. Also openssl is under Apache License which
makes it a lot easier to use it in combination with other software.

Cheers,
Klaus




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