Re: [Standards] NEW: XEP-0390 (Entity Capabilities 2.0)
Fri, 26 May 2017 18:41:17 +0200 Daniel Gultsch wrote: > would sending in presence work? If we choose to use presences, then why even bother with putting caps in features? If we choose to use stream elements, we can send nonza. I think there should be some consistency. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO and Olm
On Fri, 26 May 2017 at 19:29, Philipp Hörist wrote: > We can make everyone happy, if we just ask around and find someone that is > willing to add XEdDSA to OLM. > Not everyone. I won't be happy until one can easily make an independent implementation of this XEP. For me, this means it needs to be built on generally available crypto primitives. Concretely, this means 1 of 2 possibilities (as stated earlier): - Keep the current XEP (i.e. Olm as it is today). It is trivial to implement independently today, with several alternatives of crypto libraries. It just needs to be specified properly (split identity keys). - We change the XEP to use XEdDsa, and someone gets an implementation into an (peer reviewed and preferably established) crypto library, *independent* of libolm. The second path is more work, uncertain, and will take time. But if this is a price we want to make to keep the current (4?) OMEMO clients happy, then so be it. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO and Olm
Hi, 2017-05-26 19:28 GMT+02:00 Philipp Hörist : > We can make everyone happy, if we just ask around and find someone that is > willing to add XEdDSA to OLM. > > 1. Then we have it in a lib with a license that makes us happy > 2. We can write the XEP so that libsignal and OLM can be used. > 3. Even the Matrix people would probably use it for their protocol once there such a method in Olm I might be able to find someone who'd be willing to pay for an audit of that particular method. It might make sense to have that done by the same people who audited the rest of Olm so maybe the Matrix people can put us in touch when the time comes. cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO and Olm
On Fri, May 26, 2017 at 12:15 PM, Remko Tronçon wrote: >> crypto is subtle, and it can be very easy to make mistakes that have >> catastrophic consequences. >> >> ... >> I haven't finished or tested it yet > > > This doesn't really give me much more confidence to be honest. Fair enough; the point is that I got enough done to think that Andy is right that the subtle crypto is handled for you; and XEdDSA is mostly just plugging up ed25519 and curve25519 implementations. Of course, doing *any* crypto comes with risks (distribution is a problem I'll ignore because that's so specific to the ecosystem you're using and isn't something we need to concern ourselves with, I think), but I think the risks in this case are "your implementation will be broken", not "your implementation will leak information or allow invalid signatures". I may be wrong, of course, frankly, I have no business analyzing or arguing about crypto, I'm just relating my experience trying my hand at an implementation with enough knowledge of how to write good crypto to hopefully not screw it up too badly. The code base where I would add this if I did complete it is audited periodically, so I'll see if they'd accept a patch in which case maybe someone will tell me if there's more too it than I think. >> If you already have an ed25519 imlementation > > Doesn't the spec say that you shouldn't rely on ed25519 implementations > for verifying signatures? Not that I see; it makes things a lot slower if your keys are generally in montgomery format because you have to do the extra scalar multiplication to convert the keys though, so you might not want to entirely delegate and convert keys back and forth every time. For my purposes this didn't matter because the API already uses all keys in edwards format (so you'd just have to do the conversion when the key came in over the wire or when you were sending an identity key back out). > Ed25519 signature verification easier to grasp than X3DH. > But maybe there's a security implication that makes the latter better? I'm not sure why it would be easier; they seem roughly the same to me, but I'm not expert. As far as I'm aware there are no security implications to using one over the other. Using the same key (for me at least) is no more than a convenience; certainly nothing I'd hold out or fight for, but it makes my libraries API nicer (one type that the ECDH code and the sign/verify code can take). It's not that big of a deal either way as far as I'm concerned. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO and Olm
We can make everyone happy, if we just ask around and find someone that is willing to add XEdDSA to OLM. 1. Then we have it in a lib with a license that makes us happy 2. We can write the XEP so that libsignal and OLM can be used. 3. Even the Matrix people would probably use it for their protocol So lets do this. thanks, Philipp 2017-05-26 19:15 GMT+02:00 Remko Tronçon : > > crypto is subtle, and it can be very easy to make mistakes that have >> catastrophic consequences. >> > ... >> I haven't finished or tested it yet >> > > This doesn't really give me much more confidence to be honest. > > I understand that copy pasting code and to get a working version of the > pseudocode is easy. The devil, however, is in the details, as you say. And > this isn't just > about code, but also about distributing the (crypto) code, which also comes > with subtleties. > > If you already have an ed25519 imlementation >> > > Doesn't the spec say that you shouldn't rely on ed25519 implementations > for verifying signatures? > > >> being able to use a single key for both ECDH and signatures is really >> nice. >> > > I don't understand yet why this is 'nice', so maybe someone should explain > it to me. > AFAICT, there's no difference from the user's POV (both cases have a > single key > that is used to authenticate), and I always found a simple 3DH combined > with a standard > Ed25519 signature verification easier to grasp than X3DH. > But maybe there's a security implication that makes the latter better? > > thanks, > Remko > > ___ > 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] OMEMO and Olm
> crypto is subtle, and it can be very easy to make mistakes that have > catastrophic consequences. > ... > I haven't finished or tested it yet > This doesn't really give me much more confidence to be honest. I understand that copy pasting code and to get a working version of the pseudocode is easy. The devil, however, is in the details, as you say. And this isn't just about code, but also about distributing the (crypto) code, which also comes with subtleties. If you already have an ed25519 imlementation > Doesn't the spec say that you shouldn't rely on ed25519 implementations for verifying signatures? > being able to use a single key for both ECDH and signatures is really nice. > I don't understand yet why this is 'nice', so maybe someone should explain it to me. AFAICT, there's no difference from the user's POV (both cases have a single key that is used to authenticate), and I always found a simple 3DH combined with a standard Ed25519 signature verification easier to grasp than X3DH. But maybe there's a security implication that makes the latter better? thanks, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] NEW: XEP-0390 (Entity Capabilities 2.0)
Hi, 2017-05-26 18:38 GMT+02:00 Jonas Wielicki : > On Freitag, 26. Mai 2017 19:15:33 CEST Evgeny Khramtsov wrote: >> I >> assume the features should be cached by the peer, but how to update the >> cache if the server has changed configuration in runtime? > > That’s a good point. I haven’t thought about that specifc issue, I was mostly > concerned with updating the algorithm for the hash input. > > I am open for suggestions on how to solve this. would sending in presence work? Depending on how the client side implementation looks like that would probably make it work out of the box. (Given that all jids are actual to the server) I'm not sure though if there is any unwanted meaning in sending a presence. cheers Daniel ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] NEW: XEP-0390 (Entity Capabilities 2.0)
On Freitag, 26. Mai 2017 19:15:33 CEST Evgeny Khramtsov wrote: > I > assume the features should be cached by the peer, but how to update the > cache if the server has changed configuration in runtime? That’s a good point. I haven’t thought about that specifc issue, I was mostly concerned with updating the algorithm for the hash input. I am open for suggestions on how to solve this. kind regards, Jonas 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] OMEMO and Olm
> Yes, it's true that there's currently no such thing [a permissively licensed > implementation] for XEdDSA … > implementing this yourself really isn't > that complex. You can re-use existing EdDSA code, all you need to do is > write the key conversion code yourself, for which there is pseudo-code in > the standard, which maps fairly directly to well-known mathematical > primitives, for which you can also re-use existing code. The main novel idea > in XEdDSA is resolving an ambiguity in the conversion by forcing a sign bit > to 0, and that's about it. Your code doesn't have to be constant-time and if > you do it wrong, the signature just won't verify. This is my only real concern with using XEdDSA as it stands today; crypto is subtle, and it can be very easy to make mistakes that have catastrophic consequences. To find out, I decided to do an implementation of XEdDSA and see how difficult it was. I haven't finished or tested it yet (and I'm not sure if I'm going to or not), but I've gotten far enough to come to the conclusion that Andy is right: If you already have an ed25519 imlementation (and possibly a curve25519 implementation if you want to use the montgomery form of the keys, I skipped this part and just used edwards keys directly) then it's fairly straight forward. The hardest part is interpreting the spec (crypto people like to use notations that make me sad and probably make it easier to make a mistake). All that being said, I still would prefer if there were other existing implementations; relying on software that doesn't exist except in GPLed form still feels poor to me, but being able to use a single key for both ECDH and signatures is really nice. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] NEW: XEP-0390 (Entity Capabilities 2.0)
Fri, 26 May 2017 14:50:52 + (UTC) XMPP Extensions Editor wrote: > Version 0.1 of XEP-0390 (Entity Capabilities 2.0) has been released. In section 5.2 there is the same problem as in the predecessor: I assume the features should be cached by the peer, but how to update the cache if the server has changed configuration in runtime? Using disco polling is ridiculous, because in this case "caps-in-features" makes very little sense. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] NEW: XEP-0390 (Entity Capabilities 2.0)
Version 0.1 of XEP-0390 (Entity Capabilities 2.0) has been released. Abstract: This document overhauls the XMPP protocol extension Entity Capabilities (XEP-0115). It defines an XMPP protocol extension for broadcasting and dynamically discovering client, device, or generic entity capabilities. In order to minimize network impact, the transport mechanism is standard XMPP presence broadcast (thus forestalling the need for polling related to service discovery data), the capabilities information can be cached either within a session or across sessions, and the format has been kept as small as possible. Changelog: [See revision history] (jwi) Diff: https://xmpp.org/extensions/diff/api/xep/0390/diff/0.0.1/vs/0.1 URL: https://xmpp.org/extensions/xep-0390.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0369 (Mediated Information eXchange (MIX))
Version 0.9.2 of XEP-0369 (Mediated Information eXchange (MIX)) has been released. Abstract: This document defines Mediated Information eXchange (MIX), an XMPP protocol extension for the exchange of information among multiple users through a mediating service. The protocol can be used to provide human group communication and communication between non-human entities using channels, although with greater flexibility and extensibility than existing groupchat technologies such as Multi-User Chat (MUC). MIX uses Publish-Subscribe to provide flexible access and publication, and uses Message Archive Management (MAM) to provide storage and archiving. Changelog: Fix xmpp:nodes typos; Remove namespace references in Info/Config nodes; Modify Participant and JID Map syntaxes; Clarifications on subscription to participants node and using this to receive Nick changes; Replace use of "query" as MIX defined operations for setting nick; (sek) Diff: https://xmpp.org/extensions/diff/api/xep/0369/diff/0.9.1/vs/0.9.2 URL: https://xmpp.org/extensions/xep-0369.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes
On Fri, May 26, 2017 at 9:43 AM, Kevin Smith wrote: > In the meantime, I’ve set up mail on the host and confirmed it can send to > XSF lists as edi...@xmpp.org. Thanks, that seems to be working; hardhats on for incoming mail flood please! —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] DEPRECATED: XEP-0016 (Privacy Lists)
Version 1.7 of XEP-0016 (Privacy Lists) has been released. Abstract: This specification defines an XMPP protocol extension for enabling or disabling communication with other entities on a network. The protocol, which was first standardized in Section 10 of RFC 3921, can be used to block communication with unknown or undesirable entities. Blocking can be based on Jabber Identifier, subscription state, or roster group. The blocked stanzas can be messages, IQs, inbound or outbound presence stanzas, or all stanzas. The protocol also enables an entity to create, modify, or delete its privacy lists, apply different lists to different connected resources, define a default list, and decline the use of any privacy list during a particular communications session. Changelog: Deprecating by vote of the council. (XEP Editor: ssw) Diff: https://xmpp.org/extensions/diff/api/xep/0016/diff/1.6/vs/1.7 URL: https://xmpp.org/extensions/xep-0016.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] RETRACTED: XEP-0326 (Internet of Things - Concentrators)
Version 0.4 of XEP-0326 (Internet of Things - Concentrators) has been released. Abstract: Note: This specification has been retracted by the author; new implementations are not recommended. This specification describes how to manage and get information from concentrators of devices over XMPP networks. Changelog: [See revision history] (XEP Editor: ssw) Diff: https://xmpp.org/extensions/diff/api/xep/0326/diff/0.3/vs/0.4 URL: https://xmpp.org/extensions/xep-0326.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] RETRACTED: XEP-0325 (Internet of Things - Control)
Version 0.5 of XEP-0325 (Internet of Things - Control) has been released. Abstract: Note: This specification has been retracted by the author; new implementations are not recommended. This specification describes how to control devices or actuators in an XMPP-based sensor network. Changelog: [See revision history] (XEP Editor: ssw) Diff: https://xmpp.org/extensions/diff/api/xep/0325/diff/0.4/vs/0.5 URL: https://xmpp.org/extensions/xep-0325.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] RETRACTED: XEP-0324 (Internet of Things - Provisioning)
Version 0.5 of XEP-0324 (Internet of Things - Provisioning) has been released. Abstract: Note: This specification has been retracted by the author; new implementations are not recommended. This specification describes an architecture for efficient provisioning of services, access rights and user privileges in for the Internet of Things, where communication between Things is done using the XMPP protocol. Changelog: [See revision history] (XEP Editor: ssw) Diff: https://xmpp.org/extensions/diff/api/xep/0324/diff/0.4/vs/0.5 URL: https://xmpp.org/extensions/xep-0324.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] RETRACTED: XEP-0323 (Internet of Things - Sensor Data)
Version 0.6 of XEP-0323 (Internet of Things - Sensor Data) has been released. Abstract: Note: This specification has been retracted by the author; new implementations are not recommended. This specification provides the common framework for sensor data interchange over XMPP networks. Changelog: [See revision history] (XEP Editor: ssw) Diff: https://xmpp.org/extensions/diff/api/xep/0323/diff/0.5/vs/0.6 URL: https://xmpp.org/extensions/xep-0323.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes
On 26 May 2017, at 15:33, Kevin Smith wrote: > > On 26 May 2017, at 15:22, Sam Whited wrote: >>> email is an issue of Editor tooling, rather than iteam, and we can resolve >>> that there. >> >> Is it? I don't think it's a tooling issue; the script appears to be >> working exactly as it was before, mail is just never showing up on the >> server. I assumed EOS didn't have its mail agent setup correctly or >> that it was actually being sent but being blocked by the list since >> it's from a new address or something. > > In the sense that, as I said back when the server loss first happened, I > think we should update the scripts to run from Editors’ workstations, rather > than needing to be run on the web server. In the meantime, I’ve set up mail on the host and confirmed it can send to XSF lists as edi...@xmpp.org. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes
On 26 May 2017, at 15:22, Sam Whited wrote: >> email is an issue of Editor tooling, rather than iteam, and we can resolve >> that there. > > Is it? I don't think it's a tooling issue; the script appears to be > working exactly as it was before, mail is just never showing up on the > server. I assumed EOS didn't have its mail agent setup correctly or > that it was actually being sent but being blocked by the list since > it's from a new address or something. In the sense that, as I said back when the server loss first happened, I think we should update the scripts to run from Editors’ workstations, rather than needing to be run on the web server. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes
On Fri, May 26, 2017 at 9:10 AM, Kevin Smith wrote: > I’ve now given the editors the ability to deploy a new docker image with the > aforementioned script. Thank you; one down. > email is an issue of Editor tooling, rather than iteam, and we can resolve > that there. Is it? I don't think it's a tooling issue; the script appears to be working exactly as it was before, mail is just never showing up on the server. I assumed EOS didn't have its mail agent setup correctly or that it was actually being sent but being blocked by the list since it's from a new address or something. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes
> On 26 May 2017, at 14:56, Kevin Smith wrote: > > On 26 May 2017, at 14:41, Sam Whited wrote: >> Sam and Dave think it still involves manual steps. >>> >>> It does, as it has always done. >> >> Those manual steps have never involved being dependent on another team >> though, which is the actual problem. > > Well, the good news is that this has been whined about enough that I’ve just > tried to do something about it, and broken the server in the process. > > So you were wrong, it used to be possible to publish XEP updates. > > But now you’re right. And thankfully Edwin is much smarter than me, has fixed sudo (thank you), and I’ve now given the editors the ability to deploy a new docker image with the aforementioned script. So I think that means the first non-issue is resolved and the remaining complaint about email is an issue of Editor tooling, rather than iteam, and we can resolve that there. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes
On 26 May 2017, at 14:41, Sam Whited wrote: > >>> Sam and Dave think it still involves manual steps. >> >> It does, as it has always done. > > Those manual steps have never involved being dependent on another team > though, which is the actual problem. Well, the good news is that this has been whined about enough that I’ve just tried to do something about it, and broken the server in the process. So you were wrong, it used to be possible to publish XEP updates. But now you’re right. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes
>> Sam and Dave think it still involves manual steps. > > It does, as it has always done. Those manual steps have never involved being dependent on another team though, which is the actual problem. On Fri, May 26, 2017 at 3:31 AM, Kevin Smith wrote: > I did say that the Editor scripts to send mail might need adjusting. I can't > immediately think of any reason announcement mails need to be sent from eos, > though. I would prefer that these didn't come from my personal email, and I would also like to not have to copy/paste/edit a template every time. It's just one more step in an already cumbersome process. —Sam ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes
On 26 May 2017, at 09:26, Tobias M wrote: > > >> On 26. May 2017, at 10:17, Kevin Smith wrote: >> >> I don’t see any reason to do this, we’re able to publish XEP updates just >> fine. > > According to Sam, eos can’t send emails, like the XSF Editor emails that > announce XEP changes or new ProtoXEPs. I did say that the Editor scripts to send mail might need adjusting. I can't immediately think of any reason announcement mails need to be sent from eos, though. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes
> On 26. May 2017, at 10:17, Kevin Smith wrote: > > I don’t see any reason to do this, we’re able to publish XEP updates just > fine. According to Sam, eos can’t send emails, like the XSF Editor emails that announce XEP changes or new ProtoXEPs.___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] [Council] 2017-05-17 Council Meeting Minutes
On 24 May 2017, at 14:48, Tobias Markmann wrote: > ## XSF Editor infrastructure state > > Tobias asks Sam (with his editor hat on) about the current state of XSF > Editor infrastructure and their ability to publish and otherwise process XEP > changes. Without this ability it makes little sense to the XMPP Council to > vote on new XEPs. > > Sam is unclear about the current state and though it was not working yet, > while Kev saying in the morning that it was and that he's working on > automating some processes. To publish new XEPs the Editors simply have to commit the new versions, and then drop me (or others on iteam) a mail asking for the container to be redeployed. I believe some of the Editor scripts that send email might need adjusting, but from an iteam-deploying-XEPs-to-the-website point of view everything of which I’m aware is working (I have tested deploying stuff and it seems ok - the only current wibble is that the website itself doesn’t correctly list XEP versions on the index; I’m hoping to look at this soon). > * Dave joins * > > Sam and Dave think it still involves manual steps. It does, as it has always done. > We decide to hold off further XMPP Council actions for the XSF Editor as it > would just queue up actions without visible results. I don’t see any reason to do this, we’re able to publish XEP updates just fine. /K ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
