Re: [Standards] Disappearing timers for OMEMO proposal
> In federated environment you can't control what client is used > by remote party, and if it really does delete messages after timer expires. True, but it would still be a useful in a situation where you trust the other parties (e.g. non-federated setup where you know which clients are being used). And even in a non-federated environment, you can't be sure that the other side doesn't retain your messages, so there's always trust involved. I don't see why a XEP for data retention hints needs to be tied to other XEPs like OMEMO, though. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed XMPP Extension: Message Markup
Hi, On 7 November 2017 at 21:34, Jonas Wielicki wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > Minor remark: the XEP says that spans MUST NOT overlap. Is there a reason for this? I'm asking, because the systems I have seen that use external markup like this don't impose this. I'm not sure if this will ever matter, but this makes adding a bit of style to a piece of text non-incremental (you can't just add a , you need to break up existing spans). thanks, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] OMEMO Key Agreement
Hi, A few months ago, there were discussions around the OMEMO key agreement protocol, which we said we'd revisit once the XEP was changed to document the historical SIACS protocol, and we then could move on to making OMEMO future-proof. With all that out of the way, i'm picking this up again now. The problem with the current key agreement is that it relies on XEdDSA, a custom cryptographic primitive, not generally available in established libraries (OpenSSL, LibSodium, ...), blocking further adoption of OMEMO. It would be better for both practical, risk, and consistency reasons to only rely on accepted and widely available cryptographic primitives. One of the proposed solutions was to switch from a single X25519 keypair for both DH and signing keys (using XEdDSA) to an X25519 keypair for DH + an Ed25519 keypair for signing keys (using EdDSA, widely accepted), and tying both keypairs together using a signature. This is also the approach taken by Matrix in their Olm protocol. This impacts the key agreement implementations of existing SIACS clients, but we were hoping people would care less about this once the siacs XEP was published. That said, AFAICT, this stays limited to a (local) change in the implementation only, and doesn't impact the already generated keys: the currently used X25519 keys can be converted to Ed25519 keys (something which XEdDSA relies on already), so existing key validations of your contacts keys don't have to be invalidated. From the user's perspective, only fingerprints that were sent out-of-band between the switch to the new protocol will be invalidated, which is a very limited impact. Any comments on this? thanks, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Security issues with XHTML-IM (again)
> a) Is it likely that the conversion from a Markdown-like syntax will > intentionally generate malicious HTML? > Depends on the syntax. If you use markdown, I think it is unlikely to happen, because it's not tempting to implement the conversion yourself (lots of libraries, too complex to do with regexp), and libraries do the right thing (given that you turn off arbitrary HTML support). If you increase the temptation to 'roll your own' conversion (e.g. use a format that is very simple, like slack's notification format, or use something without too many libraries that you are likely to implement yourself), you'll probably see lots of regexp-like substitutions followed by direct injection. In summary: i think with Markdown, we're fine. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0384 OMEMO questions
> 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
Hi Klaus, thanks for the clarification. Is there already something done for > OMEMO-next? Where can I contribute? > I have a long list of proposals I want to submit to the XEP (many of them here https://github.com/xsf/xeps/pull/463, but some might need revisiting in light of some discussions). However, I was waiting for council to take a decision on choosing a new XEP author before putting more effort into this. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Permanent slots for HTTP Upload
> It seems that people, like Daniel, are reaching the limits of those > features and want to extend the XEP. > It sounded like Daniel's problems could be fixed with a simple addition to the XEP, and didn't warrant all the complexity of the PEP-based protocol you describe. This all sounds way beyond what a client needs (and wants) to implement. (the fact that it's based on existing XEPs doesn't necessarily make it easy to implement) thanks, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] HTTP-Upload: Content-based slots
> Clearly, benefits, but I do wonder what can of worms this opens with > regards to confidentiality. "Wait, someone else uploaded this?" > I agree you need to be careful to leak information here, and e.g. only do this if it was the same user that uploaded it. Maybe there are other reasons for passing the hash in the . But then again, maybe this use case is too contrived to require it. > There is also talks about being able to update content (which I personally dislike) - but your proposal adds quite a bit of complexity there too. A server with dynamic/content-based filenames and updating indeed don't go well together. IMO, allowing updating in itself brings complexity on the server (need to manage permissions) and the client (you need to decide whether you want to re-download files based on cache expiration etc., chat history can change if inline images are updated, ...), so I also prefer to drop update support, and just provide a protocol for uploading files and getting URLs to them. Another reason I can think of for content-based GET URLs is that clients sometimes upload files with incorrect extensions (PNG as JPG), and that some web viewers and frameworks make decisions based on filename extensions (I think I've seen web-based audio players give problems if the files have the wrong extension). A server may want to correct this. Alternatively, it could give an HTTP error, but then we would need to standardize on that too, and users are often baffled by incorrect extension problems. thanks, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] HTTP-Upload: Content-based slots
Hi, A server may want to provide optimized write-once storage of files that stores data based on hashes of file contents (such that identical files are only stored once, and that filenames are opaque). In this light, I was wondering whether the following extensions to XEP-0363 would make sense: - Provide a hash of the contents in the , such that the server can make decisions on upload slot response based on the hash (e.g. give a response that this file has already been uploaded). - The ability to omit the from the slot response, and have it be returned as the HTTP PUT response, such that the server can delay deciding what the GET URL will be after it has seen the contents). thanks, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Reputation system for XMPP
> Also, it might be easier to control this sort of thing in a silo like > Signal than in a federated network like XMPP. It's definitely easier for them, since they don't have to federate with badly setup servers that leave doors wide open, and their own users need to verify a phone number before they can connect. > When I log in and receive dozens of spam messages, that's a degraded user experience No argument from me here: I think XMPP spam is a problem that needed solving yesterday. Remko, what do you suggest? > I was sort of hoping that you would come up with a magic trick after getting through your reading list. I don't see an easy solution. Looking at my account, my guess is badly setup servers are the biggest problem today. Servers probably need to tighten their registration (e.g. no IBR, harder proof of validity), server vendors might take steps to discourage bad setups (e.g. make it hard to enable IBR), but you'll always have to deal with the case of badly setup servers (and eventually malicious servers) on a federated network, so you'll need to have S2S checks. I was also thinking of a reputation-based system for S2S (with a blacklist as an extreme), assuming that the reputation can propagate fast enough to handle a spam attack (I don't know the dynamics of spam sent through XMPP). You'll probably also need some smart content-based spam-detection systems contributing to the reputation. I haven't checked, but my gut feeling tells me that starting with basing reputation purely on whether IBR is enabled or not (which every server can detect for itself) would probably prevent most of the spam I get today. (my personal XMPP domain blacklist is available on request for anyone wanting to write a script to invalidate or validate this claim ;-)) In the end, though, you'll end up with a likelihood score of a message being spam, so I still think it'll be up to the client to make the call whether and how to display it. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Reputation system for XMPP
> On 5 Sep 2017, at 09:27, Kevin Smith wrote: > > Together with only accepting messages from entities you’ve sent presence to, > this should more or less completely prevent spam, This seems to be a recurring theme, and I'm not sure I like it. This couples presence (and the roster) even more tightly with messaging than it already is. I was hoping XMPP could be used purely for messaging in some cases, without necessarily having to deal with presence subscriptions (e.g. like Signal) Guiding clients down the path of (silently) rejecting messages without presence kills this use case, even for clients that decide not to do this but still want to talk to other clients. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Discussion Summary 2017
On 22 June 2017 at 09:48, Daniel Gultsch wrote: > Questions for OMEMO-NEXT for the new author to collect feedback on. > (Each of them deserves it's own thread) > Another category of questions that I think need to be added to that list is around key exchange and trust, bearing usability in mind: - How are keys validated (i.e. what's the fingerprint? Is there a fingerprint per contact, or per conversation (like what Signal does)? What in the case of multiple devices?). - Recommendation of trust models (e.g. TOFU) - Are there extensions needed to make adding new devices more usable (e.g. cross-signing of own keys to not break the TOFU model when a new device is added for the same JID). Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Discussion Summary 2017
Hi Ignat, I somehow got the feeling that some people on this mailing list actually > don't want the OMEMO standard to evolve, when it does not include the > changes they want. > I agree, I get the same feeling. > As it seems to be the "compromise" to not evolve OMEMO in the near future > and we have a roadmap to finish e2e-encryption by end of the year, there > was no choice left then to go this step. > I don't think the compromise is to not evolve things. On the contrary, it is to unblock things so it can actually move much faster again (instead of changes from the outside being ignored for months on end because of misperceptions of the XEP). > We might release some of our non-libsignal-based development later this > year as open-source, but I bet it will be GPL licensed and not under one of > those "make money with third-party software and run away with it"-licenses > that are so much liked by some of the people (representing their companies > interest) here. > You're of course more than welcome to do so. If I were to have a commercial interest in XMPP and/or OMEMO, I probably would use GPL as well. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] LAST CALL: XEP-0186 (Invisible Command)
Hi, > This Last Call begins today and shall end at the close of business on 2017-03-14. FYI, this XEP seems to be in last call after its end date. > 1. Is this specification needed to fill gaps in the XMPP protocol stack or > to clarify an existing protocol? Yes. AFAICT, there's no other way to reliably have conversations using XMPP without exposing presence information to (other) contacts. > 2. Does the specification solve the problem stated in the introduction and > requirements? Yes. > 3. Do you plan to implement this specification in your code? If I had time, it would be high on my list :) > 4. Do you have any security concerns related to this specification? Not beyond what's stated in section 6. > 5. Is the specification accurate and clearly written? Yes. Note that server implementations oft his XEP currently seem to be very scarce. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Encrypted Jingle File Transfer
> On 6 Jun 2017, at 13:02, Dave Cridland wrote: > > it might well be worth looking at XEP-0200 for full-stanza encryption Yeah, makes sense. Something like xmlenc gives you precise control over which parts you encrypt, but we probably don't need (or even want) that. This way, clients just need to decide whether to encrypt, not what. I do think this belongs in the OMEMO XEP (and that the OMEMO XEP needs to change to generic stanza encryption instead of just 'message body'), such that this XEP only has to focus on defining encryption of the data stream. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement
Hi Sebastian, > I was going to suggest using seperate key-pairs: one for signing and one for DH. However, upon closer inspection it seems that the X3DH-specification requires XEdDSA signatures (https://whispersystems.org/ docs/specifications/x3dh/#cryptographic-notation), so if you did that you would no longer follow the open specs, which I believe (from previous discussions) is not desirable. Personally, I'm fine with changing the key agreement protocol, as long as it is validated by (an) expert(s). I'm less fine with limiting implementation options, which is why separate key-pairs is my preferred direction as well. So there is no long-term key involved in the key agreement? > This is probably a misunderstanding of my part. Initially, I assumed that IK was indeed a long-term key, but then in I read that it should theoretically be rotated [1] (but isn't), so then I was thinking it was more like a signed pre-key key (but that authentication was ensured by verifying signatures). Remko [1] https://matrix.org/docs/guides/e2e_implementation.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Encrypted Jingle File Transfer
On 4 June 2017 at 15:45, Vanitas Vitae wrote: > Thank you for your suggestion. I didn't knew about xmlenc, but it looks > like it is (for now) only available for java, so restricting algorithms > etc. definitely sounds like a good idea. > FYI, there's also XMLSec, the LibXML2-based C library, which has bindings in many languages: https://www.aleksey.com/xmlsec/ I used that to play around with xmlsec recently. Remko > > Am 04.06.2017 um 15:31 schrieb Remko Tronçon: > > Hi Vanitasvitae! > > I wonder if it would make sense to use something like xmlenc to have a > 'generic' way to encrypt (parts of) stanzas. This way, you can decouple the > encryption key info etc. from the things you want to encrypt, and you can > choose to encrypt entire elements, or just parts of elements. > > For example, if you want to encrypt the entire metadata: > > > > > BASE64ENCODED... > BASE64ENCODED... > ... > > > action='session-initiate' >initiator='romeo@montague.example/dr4hcr0st3lup4c' >sid='851ba2'> > > > > http://www.w3.org/2001/04/xmlenc#"; Type=" > http://www.w3.org/2001/04/xmlenc#Element";> > http://www.w3.org/ > 2001/04/xmlenc#aes256-cbc"/> > http://www.w3.org/2000/09/xmldsig#";> > omemo > > > /7VSyS4tbcfsq7JYhZRgQE8bNkiyUJK > i68FdmdoA2PIRjGumbfI35X2om/4mbfHteCAEBATpsr/l/ > HvQf7GERGtvmuupNFh7reGeSWl8wajwwYyfQi9BM6MfjZKi8D9Q94FhWz2p0 > LMVEjduI9svzKOf/uLI3JolK39nH70ezvyYebybpasDxC51SypmVU1p > > > > > > > > Or, if you just want to encrypt only parts of the (e.g. not the > hash) > > > > > BASE64ENCODED... > BASE64ENCODED... > ... > > > action='session-initiate' >initiator='romeo@montague.example/dr4hcr0st3lup4c' >sid='851ba2'> > > > > w0mcJylzCn+ > AfvuGdqkty2+KP48= > > > http://www.w3.org/2001/04/xmlenc#"; Type=" > http://www.w3.org/2001/04/xmlenc#Content";> > http://www.w3.org/ > 2001/04/xmlenc#aes256-cbc"/> > http://www.w3.org/2000/09/xmldsig#";> > omemo > > > > /7VSyS4tbcfsq7JYhZRgQE8bNkiyUJKi68FdmdoA2PIRjGumbfI35X2om/ > 4mbfHteCAEBATpsr/l/HvQf7GERGtvmuupNFh7reGeSWl8waj > wwYyfQi9BM6MfjZKi8D9Q94FhWz2p0LMVEjduI9svzKOf/ > uLI3JolK39nH70ezvyYebybpasDxC51SypmVU1p > > > > > > > > > KeyInfo could be used to distinguish where the key material is coming from > for encryption (e.g. OMEMO element at the top of the IQ). > > I'm not saying xmlenc is very elegant, and it's very broad, but it has the > advantage that you may get an implementation for free in your language? It > might need some restricting of possible algorithms/keys/... for clients > that need to implement this themselves if they don't have xmlenc available. > > 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 > ___ > > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Encrypted Jingle File Transfer
Hi Vanitasvitae! I wonder if it would make sense to use something like xmlenc to have a 'generic' way to encrypt (parts of) stanzas. This way, you can decouple the encryption key info etc. from the things you want to encrypt, and you can choose to encrypt entire elements, or just parts of elements. For example, if you want to encrypt the entire metadata: BASE64ENCODED... BASE64ENCODED... ... http://www.w3.org/2001/04/xmlenc#"; Type=" http://www.w3.org/2001/04/xmlenc#Element";> http://www.w3.org/2001/04/xmlenc#aes256-cbc"/> http://www.w3.org/2000/09/xmldsig#";> omemo /7VSyS4tbcfsq7JYhZRgQE8bNkiyUJKi68FdmdoA2PIRjGumbfI35X2om/4mbfHteCAEBATpsr/l/HvQf7GERGtvmuupNFh7reGeSWl8wajwwYyfQi9BM6MfjZKi8D9Q94FhWz2p0LMVEjduI9svzKOf/uLI3JolK39nH70ezvyYebybpasDxC51SypmVU1p Or, if you just want to encrypt only parts of the (e.g. not the hash) BASE64ENCODED... BASE64ENCODED... ... w0mcJylzCn+AfvuGdqkty2+KP48= http://www.w3.org/2001/04/xmlenc#"; Type=" http://www.w3.org/2001/04/xmlenc#Content";> http://www.w3.org/2001/04/xmlenc#aes256-cbc"/> http://www.w3.org/2000/09/xmldsig#";> omemo /7VSyS4tbcfsq7JYhZRgQE8bNkiyUJKi68FdmdoA2PIRjGumbfI35X2om/4mbfHteCAEBATpsr/l/HvQf7GERGtvmuupNFh7reGeSWl8wajwwYyfQi9BM6MfjZKi8D9Q94FhWz2p0LMVEjduI9svzKOf/uLI3JolK39nH70ezvyYebybpasDxC51SypmVU1p KeyInfo could be used to distinguish where the key material is coming from for encryption (e.g. OMEMO element at the top of the IQ). I'm not saying xmlenc is very elegant, and it's very broad, but it has the advantage that you may get an implementation for free in your language? It might need some restricting of possible algorithms/keys/... for clients that need to implement this themselves if they don't have xmlenc available. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement
Hi Sebastian, Thanks for your feedback, it's insightful. > Remko, generally speaking there are some issues with your proposal. I think we ended up agreeing that the way I was looking for compromises wasn't ideal for future-proofness. Apparently, it also has cryptographical problems. I don't think we should dig into this further or try to fix it. > The fingerprints of the Signal protocol have been crafted such that you can publish your fingerprint on long-term media (on your business-card would be a typical scenario). Right, I wasn't saying it wasn't. I was saying that breaking fingerprints to get to a protocol where we are all comfortable with would be suboptimal, but maybe wasn't a dealbreaker. Even Signal changed their fingerprints AFAIK [1] (although perhaps in a way that people who really wanted to could decompose the new format and still reuse their fingerprints) As a sidenote, "crafted for printing" depends how you look at it. Signal fingerprints are per-conversation. From [1], I understand that to get something to put on a business card, you need to split the fingerprint, figure out which half is yours, and the other party needs to know how to interpret this and do the same. So it's not really part of the flow they're trying to push, but it can be done if you really wanted to. > This confuses me. > This is not just a difference of terminology, but these are cryptographically different operations. The terminology comes from an Olm document. My point (and others pointed this out to me as well) was indeed that this terminology was confusing, and probably needs to change. I also didn't mean to say that X3DH and 3DH are the same of course. My point in that mail was to point out that I think that modifying libsignal to do Olm's 3DH doesn't require a full rewrite of all clients. But I get that reusing the identity key only for signing but not for 3DH might have issues (and another upgrade path might need to be found). > I don't think you are missing anything here. As long as you tie your keys together (for example, by signing your DH-key with your signing key) this sounds fine. The reason to introduce XEdDSA is not having to change the key fingerprint, a usability point. > Just introduce a fourth DH in your initial handshake and you get the best of both worlds. Am I understanding you correctly that using Olm as it is defined today (combined with separate keys for signing and DH, and signing the DH key) can work, but that the key agreement can be improved (i.e. add a 4th DH) to get the extra properties that Signal gives you? I don't understand yet what the 4th DH does, though. Given that I_b is signed (and can be replaced from time to time), I was assuming this corresponds to the signed prekey instead of the identity keys from X3DH. This would mean that Olm's 3DH doesn't use a long-standing identity key in its key agreement (it's only used to sign the prekey), and that Olm's 3DH involves signed prekeys from both parties (does this impact deniability?). thanks! Remko [1] https://www.whispersystems.org/blog/safety-number-updates/ ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement
On 2 June 2017 at 09:56, Dave Cridland wrote: > Is that a fair summary? > Yes. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO and Olm
Hi, I don't think this has much impact on the current discussion, but I'd like to come back to this for the record (and it may be relevant as an upgrade path): On 31 May 2017 at 01:40, Chris Ballinger wrote: > I don't have opposition to using Olm for any other reason than it will be > costly to rewrite all of the existing clients. Thinking about this a bit more, I don't think switching libsignal-based clients to use Olm (the algorithm) with split identity keypairs would cause a rewrite, or even lose any current identity keys. In fact, it would probably even less work than my first proposal for a key agreement compromise. I think the choice of terminology was making this sound worse than it was. What Olm (and the PR) calls the 'fingerprint key' and 'identity key' correspond in libSignal terms to 'identity key' (long-standing key, authenticated, never changes) and 'signed prekey' (a key that is signed by the authenticated key, and changed from time to time). With this terminology change, switching LibSignal-based clients to use Olm would require 3 local changes: - LibSignal's internal Curve25519 identity keys are converted to Ed25519 before publishing. (same as in my key agreement proposal). This is 1 extra call to a function (of which the code is already in libsignal) right before publishing the identity key, outside libsignal. - Signature verification is changed to use EdDSA instead of XEdDSA (same as in my key agreement proposal). This is a matter of changing one function call to another in libsignal (this function is already in libsignal) - Shared secrets are computed using 3DH on (signedPreKey, oneTimeKey_a, oneTimeKey_b) instead of X3DH on (identityKey, signedPreKey, oneTimeKey_a, oneTimeKey_b). This requires deleting 1 function call in libsignal. Applying these local changes should be enough to change any existing libsignal-based client into an Olm-compatible client. The difference with my first key agreement proposal is that this brings us back to a reviewed protocol (instead of a slightly modified libsignal one), and does not require adding the Ed2Curve conversion function to libsignal (all the required functions are already there). Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement
Hi Florian, On 31 May 2017 at 23:50, Florian Schmaus wrote: > I think it is unrealistic to > push a change that will render the currently used fingerprints invalid. > Just on this (because it might be relevant later): I think you're making fingerprint changes sound worse than they are. The only thing that gets lost is people who authenticated fingerprints out-of-band, but haven't yet confirmed this in their client and then upgrade. This could be as easy as a warning before upgrading "Do you have any fingerprints that you still haven't validated in the app". Even Signal (who seem very focused on UX) changed their fingerprints at some point AFAIK. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement
Hi Daniel, a lot of what Dave said about future proofing spoke to me and I'm > starting to think he (and the others) are right. > Thanks for trying to see it from another perspective. My motivation in this discussion has indeed always been future-proofing. > It would become an > Informational XEP (or maybe historical). Given the multiple implementations of siacs, a historical XEP sounds like a good idea to me regardless of the outcome of your current proposal. And it might indeed take the heat of discussions. > rolling the dice again and again until the key matches some > criteria doesn't sound like something that should be in a standard. > I agree. > Client authors who are looking for a short term solution (and can live > with the downsides) can implement OMEMO while all the protocol work > would go into OMEMO-NEXT. > That sounds reasonable to me. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement v2
On 31 May 2017 at 21:02, Daniel Gultsch wrote: > Is the Curve25519 to Ed25519 conversion code available in a > significant number of liberally licensed crypto libraries? > Depends on what you call 'crypto libraries', but: LibSodium (C, so can have bindings in any language), ed2curve-js (JavaScript), agl/ed25519 (Go), Chaos.NaCL (C#), orlp/ed25519 (C), ... OpenSSL has only recently gotten Ed25519 support, so they might get a similar conversion function eventually (given it's in libsodium). If you follow the "XEdDSA is simple to implement" school, then this conversion is even simpler to implement in the library of your choice. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement
On 31 May 2017 at 20:44, Daniel Gultsch wrote: > Well not going against the entire OMEMO community would be a first > good step. > This is harsh, given all attempts I have done to find solutions that make 'the OMEMO community' happy, and open up the protocol to as many implementations as possible. To me, such a statement makes it sound like 'the OMEMO community' is not open to wider standardization if it means it requires changes that aren't proposed by them. This would be sad. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] OMEMO Key Agreement v2
Hi, Here's a proposal for the OMEMO key exchange that requires *no* changes to libsignal: Public Identity keys are Ed25519 keys with the highest bit (sign bit) 0. - LibSignal-based clients convert their internal Curve25519 identity key to Ed25519 right before the device bundle publish IQ, and convert the peer key to Curve25519 when fetching the bundle IQ. - On device initialization, non-libsignal clients guarantee a keypair that LibSignal can handle by generating identity keypairs until the highest bit of the public key is set to 0 (there's a 1 in 2 chance). Chris Ballinger seemed open to this proposal. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement
Hi Chris, On 31 May 2017 at 20:26, Chris Ballinger wrote: > What if instead of all this, we just funded a liberally licensed XEdDSA > reference implementation and got it audited? To be honest, I still think it'd be suboptimal. It would make the XEP still dependent on a single (liberal) reference implementation, in a single language. I'd much rather depend on standards that are widely accepted and available, to give OMEMO the broadest chance of implementation and deployment. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement
On 31 May 2017 at 17:42, Daniel Gultsch wrote: > The proposed solution would pretty much invalid the OMEMO protocol > audit (since important crypto parts are being changed) > If I give a solution that doesn't require *any* changes to libsignal (i.e. the compromise Chris Ballinger thought was fine), would you then still have this concern? Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement
Hi Sam, On 31 May 2017 at 16:24, Sam Whited wrote: > FWIW, this all sounds reasonable to me, but it still sounds like > trying to solve a problem that doesn't exist. > The problem still very much exists, but I'd rather not derail this thread again. At least for my part, the concerns haven't been addressed in the other thread. If we ask existing implementations to change, all > we're going to achieve is a fragmented ecosystem where half the OMEMO > enabled clients don't work with the other half. > Current implementations (using the Axolotl protocol) will break anyway, because the ODR proposal changes amongst others the info strings. This would add 2 more things to these changes. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement
Hi Ignat, So just for the record (because you didn't answer that question from my > previous mail): > This is only an implementation detail and has no relevant influence (aka, > at most constant factor) on the cryptographic properties? > I'm not a cryptographer, but as far as my knowledge goes, this is correct. > When changing the identity keys to Ed, will that mean that existing > fingerprints will become invalid? > The keys (and so existing authentications) stay valid, but if there would have been fingerprints printed, these would indeed become invalid. I'm not sure if printing fingerprints is something that is done in practice today with OMEMO anyway (as opposed to PGP). That said, I think we still want to have a discussion at some point on how to do fingerprinting anyway: verify each others public keys byte-by-byte (what OMEMO clients do today), or create a shared fingerprint (like what user-friendly clients like Signal do). Not that I have a strong opinion on either. Also, as you seem to be very concered about implementation details, > I'm not 'just' concerned about technical ability of creating independent implementations with reasonable effort, I'm also concerned about licensing and legal issues. (see other thread(s); I'd like to avoid this discussion in this thread and focus on the technical details of this compromise). > libsodium is native code only All the primitives used are available in many languages, including Java. Libsodium was just an example. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement
Hi Ignat, can you please describe the concrete benefits of your approach? > It gets rid of the non-standard XEdDSA dependency, which is blocking me (and likely others) in creating independent implementations that don't depend on libsignal. (see the other threads for my reasons). > The only difference I can spot is that it's more implementation work for > those that use libsignal (which at this point in time seems to be all > implementations) and less for libsodium (which happens to not implement > many other parts of the protocol as well and thus require a lot of work > nonetheless). > Libolm implements the rest of the protocol. I used libsodium to prove that anyone can create an independent implementation. If you want to use libolm, you'd need to change the 3DH to X3DH (same as in the prototype), and pass in an extra key (Olm doesn't have signed one-time prekeys). So it's a little bit of work for libsignal, and a bit more work for libolm. It's a compromise. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement
Hi Chris, On 31 May 2017 at 01:51, Chris Ballinger wrote: > So this is as simple as converting the Ed25519 key before ingesting into > libsignal (and vice versa)? Almost. The 'vice versa' (i.e. on the way out of libsignal) is true. The other way round (ingesting it into libsignal) would lose the sign bit, which means the signatures won't match for half (?) of the keys if you use XEdDSA. This is why the actual Ed25519 keys need to be used to do the signature verification (and since you need those, the smallest possible change is passing them through as the identity key, and doing the conversion to Curve25519 in the X3DH step; this means you don't need to pass extra stuff all the way through). AFAICT, changing the signature verification to use EdDSA should be a one-line code change to libsignal. Doing the conversion would be an extra 2 lines of code in libsignal (plus the conversion function , ±15 lines of code). The actual lines of code and information on where they need to be changed are in the prototype, but I can't try this out on a real client myself, someone like you could probably verify this in little time. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement
On 29 May 2017 at 07:53, Remko Tronçon wrote: > I may have a solution to our OMEMO key agreement discussion that satisfies > all of us. > FYI, to get some more confidence in this approach, I prototyped it using both libsignal and libsodium: https://github.com/remko/omemo-key-exchange The libsignal prototype actually mimics the 2 parts of libsignal that need to be patched; patching the library itself should be even less work/code (but I couldn't find an OMEMO client for my platform to apply the changes myself). Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Depreciating XEP-0146: Remote Controlling Clients
Hi, I'm not advocating to keep this XEP, but I think it should be deprecated or obsoleted for the right reasons (even if it is a non-normative, simple XEP as this one). On 29 May 2017 at 16:49, Daniel Gultsch wrote: > Obsolete even due to the security implications the Security > Considerations fail to mention. > Missing documentation on security implications don't make a XEP obsolete in itself I think, but means the XEP needs to be updated. > Of those, 2. is the biggest problem, at least some implementations will > > happily send a plain-text version of their logs to any other resource > > requesting it. This sounds like a problem with the implementation (most likely because of missing documentation of the implications in the XEP). Other implementations just forward the stanza as it came in (with a different envelope). > (especially 3. depending on what gets exposed), The undocumented security consideration of this XEP was "Don't do anything a server can't do anyway". I think this still holds for all the cases (unless it's badly implemented), except indeed for Case 3. All the XEPs mentioned indeed solve many of these use cases in a much more elegant way. This is why the XEP was written as an ad-hoc protocol. That said, none of the XEPs mentioned are in Draft, so technically, it hasn't been superseded yet either. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement
On 29 May 2017 at 07:53, Remko Tronçon wrote: > - We change the Identity keys to be Ed25519 keys instead of Curve25519. > To clarify this a bit further: this is only about what is published (i.e. the public part of the identity key). Internally, libsignal-based clients can still keep on using Curve25519 keys (including signing the prekeys with XEdDSA), so there's no change necessary in the state storage etc. All that needs to change is the identity publishing step, the prekey signature verification and the DH operation on the peer identity key (own identity keys are already Curve25519, so don't need Ed2Curve). The key size of the public keys is the same for Ed25519 and Curve25519, so there shouldn't be a need for type changes in the chain from key parse to X3DH in libsignal. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO Key Agreement
Hi Ignat, Unfortunately, libsodium is ISC licensed which requires carrying a > coypright/license header/file with all distributions of it. I don't > consider this a sufficiently liberal license. > This is raising the bar unreasonably high IMO. ISC is considered a permissive license (on par with BSD and MIT). That said, https://github.com/orlp/ed25519 has a key exchange method that uses this conversion, and I believe is under an even more liberal license. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] OMEMO Key Agreement
Hi, I may have a solution to our OMEMO key agreement discussion that satisfies all of us. - We change the Identity keys to be Ed25519 keys instead of Curve25519. Current client deployments are by default libsignal-based, and therefore have access to Curve25519-to-Ed25519 conversion methods to convert already authenticated keys, so they don't have to lose their keys. - We change X3DH such that - Sig(PK, M) is EdDSA(PK, M) instead of XEdDSA(PK, M) (PK is now an Ed25519 key). Libsignal already comes with an Ed25519 implementation. - DH(IK, ...) becomes DH(Ed2Curve(IK), ...). Ed25519-to-Curve25519 is a conversion that is simpler than the other way round, and there are liberally licensed implementations. Libsodium has a ref10-based one, so it can be dropped in directly into libsignal: https://download.libsodium.org/doc/advanced/ed25519-curve25519.html This drops the dependency on XEdDSA, and has a minimal impact on existing libsignal-based implementations. It *does* make the key agreement more complicated than the one in Olm (which does simple 3DH), but maybe that's a price we're willing to pay? Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO and Olm
On 28 May 2017 at 16:47, Sam Whited wrote: > You'll notice that most (all?) of OWS's ed25519 code was > copied from here, > AFAICT, everything under additions/ is either new or modified ref10 code (_modified.*), hence only available under a GPL license. This includes sc_neg.c, sc_cmov.c, sc_clamp.c. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO and Olm
> eg. CMov is an operation that copies > data if some condition is true, but without actually branching, which > makes things a lot faster Is this really true? You can do *a lot* of branches+memcpys for 3 loops over all data as far as I know. I would have guessed this was a measure against timing attacks. Where is this CMov coming from? The reason I'm nitpicking is this: even with a single properly licensed XEdDSA implementation in an unestablished library (or libolm), I still feel uncomfortable depending a XEP on it. There's a certain amount of uncertainty whether the author didn't "reuse existing bits of software" (an expression thrown around a few times on this list recently), perhaps infringing copyright in the process, making me as a software vendor vulnerable to legal attacks. This is why I asked for an implementation in an established crypto library like OpenSSL or LibSodium, where, besides review of quality, contributors sign agreements. I would then feel safer that the heat isn't directly on me if something is wrong copyright-wise with the libraries i'm using. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO and Olm
On 27 May 2017 at 17:46, Sam Whited wrote: > Here's the start of a submission to the Go crypto libraries (review > pending discussion of the proposal): > https://go-review.googlesource.com/c/44334/ > And you got all this just by looking at the XEdDSA spec? Maybe to you this is trivial, but I don't understand how parts of the pseudocode in the spec map to the code you wrote (e.g. the ScCMove bit is pure magic to me, I would never have come up with that). I still consider this way out of the comfort zone of mere mortal developers like me. Remko ___ 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
> 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] OMEMO and Olm
On 25 May 2017 at 15:53, Vanitas Vitae wrote: > So if that last part is resolved (which shouldn't be a big deal), then > Andys PR would be an accpetable compromise for everyone, am I right? > Don't forget the other part of your mail: if it also comes with one of your 2 other proposals (split ed25519/curve25519 identity keys, or (widespread) permissibly licensed implementation of XEdDSA) Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO and Olm
> > There are concerns about the usage of XEdDSA, which could be solved by > either implementing the XEdDSA conversion function in a non-GPL way This would help, but I'll still feel very uneasy until it is available in an accepted crypto library. Other than that, I agree with your summary. > Either way, are there any other points speaking against Andys PR? Yes: the wire format isn't specified (how is chain length etc. authenticated) Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO and Olm
On Thu, 25 May 2017 at 11:02, Florian Schmaus wrote: > > Thanks Dave, but Remko's statement reads like *every* OMEMO > implementation based on libsignal is legally not in order I meant to say 1, not every. Remko > ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO and Olm
On 24 May 2017 at 22:55, Andreas Straub wrote: > Yes, it's true that there's currently no such thing for XEdDSA, but is > this actually a concrete problem for anyone? Yes. I obviously can't speak for all the other clients that currently don't support OMEMO, but for Swift, XEdDSA is blocking OMEMO support for both technical and legal reasons. > 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 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. I think this is oversimplifying things. It's the same as saying implementing DH yourself is also fine, because it's just taking the modulo of 2 integers. Also, "reusing existing code" is also not something every piece of software takes lightly. > I just don't see the major implementations switching over any time soon I have serious doubts that at least one of them won't have to do *some* significant work to get rid of the libsignal dependency to be legally in order, which will mean implementing the ratchet and XEdDSA itself (unless a library emerges that implements this all from scratch). regards, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO and Olm
Hi Germán, On 19 May 2017 at 15:02, Germán Márquez Mejía wrote: > My only question is: Are there any potential privacy issues > here? > Good question. The only situation where i can see this happening is when this protocol is used in a broadcast situation, e.g.: - an anonymous/semi-anonymous MUC where an admin sends an encrypted message to all recipients (but can't get anything back). - a pubsub publication by a node owner I'm not sure whether OMEMO is well suited for PubSub or MUC use cases. (e.g for MUC, maybe we should adopt a Megolm approach for scalability), and if it is, whether the broadcast use case is something we should be concerned with. Even without sending the JID, there's still a privacy leak: you can still match 'rid's to a database of known rid->jid mappings (which is public information anyway, you just have to go out and collect it). Alternatives I can think of are: - a 'to' attribute with 'receiver' or 'initiator'. This only works in a one-on-one situation. (i.e. we'd definitely need an extension for MUC) - a 'key' attribute with the public identity key instead of a 'jid,rid' pair. This is a bit verbose (44 bytes per envelope), although not much more than 'jid,rid' (especially not if you don't impose the artificial restriction to 32-bits for device ids). thanks, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO and Olm
Hi Andrey, My 2 cents: - Clarifications (like [2] and [3]) sound sensible. There's a lot that needs better wording, clarification, disambiguation, and rationale. I think this is something that should probably be done as the dust settles on the technical details of the XEP. - For [4]: I added some rough specification of signing and verifying keys in PR #463. Can always be made clearer, but at this point, I just wanted the technical chalk lines set on paper so they can be discussed further. - For [5] (brought up by Germán Máquez Mejía): Things like 'trial and error' sound like a bad idea if they can be avoided, especially in a spec around encryption. I addressed this by adding the recipient JID in the key elements in PR #463, which guarantees the keys are collision-free (as device IDs are guaranteed to be unique per JID). thanks, Remko On 18 May 2017 at 12:57, Andrey Gursky wrote: > Hi, > > On Wed, 17 May 2017 16:59:53 +0100 Dave Cridland wrote: > > [ cut ] > > > A lengthy discussion ensued on this list, involving both Matthew > > Hodgson and others who clearly know a lot more about Crypto than I do. > > None of their arguments were answered. Remko supplied a PR to match > > these. It seems to be being ignored, then rejected out of hand. > > My emails [1..4] and an email from another one [5] regarding OMEMO > remained also without a response. > > Trying to discuss a quick fix of OMEMO jingle file-transfer was also > not welcome [6] :( > > [ cut ] > > Regards, > Andrey > > > [1] https://mail.jabber.org/pipermail/standards/2016-December/031723.html > [2] https://mail.jabber.org/pipermail/standards/2016-December/031724.html > [3] https://mail.jabber.org/pipermail/standards/2016-December/031725.html > [4] https://mail.jabber.org/pipermail/standards/2016-December/031736.html > [5] https://mail.jabber.org/pipermail/standards/2016-December/031739.html > [6] https://mail.jabber.org/pipermail/standards/2016-December/031737.html > ___ > 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] Proposed changes to OMEMO's use of PEP
On 3 April 2017 at 09:02, Florian Schmaus wrote: > Server side OMEMO support does not need to be mandatory to implement. > Given that server-side support was suggested mostly as a way for client developers to write less code, that would have the exact opposite effect. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed changes to OMEMO's use of PEP
On 26 March 2017 at 15:12, Andreas Straub wrote: > So even if we were to go this way, the timeline until we could in good > conscience actually enable this change in the client is on the order of > many, many months. Because I'm not about to break the protocol for my users. The 'this breaks current users/implementations' argument seems to come up regularly in OMEMO protocol discussions, and I don't understand why. Current users have a protocol that works: eu.siacs.conversations.axolotl. Nobody is changing that protocol, so it will work indefinitely. Existing users will never be affected. Until it reaches Draft (which can, and probably will indeed take months), everyone should expect 'urn:xmpp:omemo:0' to get breaking changes regularly. This is what 'Experimental' is for. That said, in this case, the argument "The axolotol protocol covers more *situations* than omemo:0" *is* a valid argument. So at that point, I have to ask myself, if we're already in this for the > long haul, why not actually do it right, i.e. explicit server support? If it's a valid technical question to be asked, then it needs to be asked now. Although involving the server in this would make things a bit easier on clients, I'm also concerned it brings more practical problems to rely on server availability than it solves. As you said, even if server implementors decide it is worth investing resources in implementing this custom protocol, it still makes clients rely on their server administrators to upgrade and enable this feature, which they may have less reason to for a purely end-to-end feature. Besides, for end-to-end encryption, relying on the server as little as possible sounds preferrable (although it shouldn't take away any security theoretically). Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] Proposed changes to OMEMO's use of PEP
On 26 March 2017 at 00:01, Timothée Jaussoin wrote: > This behavior can be fixed by setting pubsub#deliver_payloads to false in > the 'urn:xmpp:omemo:0' node configuration. > Bringing node configuration into a PEP-based protocol sounds like a slippery slope, and is maybe taking it too far. Doesn't this also bring in extra complexity and questions like who configures the node and when? The current split between data (which no one subscribes to) and metadata (which is subscribed to) makes sense to me, and doesn't rely on anything but PEP semantics. This approach is also used in XEP-0084 (User Avatar), which is probably the oldest PEP protocol out there. Keeping this split seems independent from the discussion whether device IDs (i.e. the metadata) should be published to separate items, and that the entire list can be queried for any new clients. XEP-0084 also publishes to different item IDs, although it doesn't rely on the entire list of metadata to be available, and if a server doesn't support item IDs, avatars would still sort of work. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA
Hi Matthew, On 31 March 2017 at 23:21, Matthew Hodgson wrote: > http://matrix.org/docs/olm_signing.html attempts to describe this > trade-off. > Thanks for sharing your insights. I didn't know about that document, and the tradeoffs and decisions you described make sense. >From my point of view, that was the only negative argument I could find against Olm. I suggest we change the XEP to move back to Olm, and extend it to include the identity key signatures and fingerprints. We'll have to decide what to do with the pre-key signatures, and document that as well. thanks, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA
On 31 March 2017 at 15:40, wrote: > It just skips the conversion part altogether, which seems to be the > central point of discussion and is not widely implemented in any direction Interesting! I believe there *is* the open question whether using the same key for signing and encrypting is a good idea, which this solution would avoid entirely. Libsignal users could reach into the library and use convert_mont to publish the same key for signing as for encrypting, avoiding the need for them to regenerate identity keys. This just leaves the receiving path of libsignal to be patched to take an arbitrary Ed25512 key instead of converting it from the X25519 key first (i don't even think the validation needs to be changed to use EdDSA, since Ed25512 signatures are also valid XEd25512 signatures according to the spec?). The fingerprints would change, but those are typically only used in a short-lived scenarios anyway? Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA
Hi Riba, > The attack is described in [1] and boils down to the following: > While I think that because of the noticability the possible damage is very limited, I kind of agree that it is not acceptable by design. One argument for 3DH might be its full deniability, which X3DH does not provide, though. Thanks, good to know. > X3DH does not rely on XEdDSA, it relies on any digital signature. Thanks for these insights. This seems to confirm my understanding so far. > If all else fails, there is always the possibility to have both a X25519 > and a Ed25519 key Right, but that would leave 2 keys to be managed and authenticated, wouldn't it? Which wouldn't be very nice from a usability POV. > but I don't really think the conversion specified in [2] qualifies as "crypto" Good to know. Unfortunately, the public key conversion part relies on low level operations AFAICT, so you'd need support from a library for practical reasons, wouldn't you? thanks, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA
On 31 March 2017 at 12:46, Dave Cridland wrote: > Surely this is trivial to fully mitigate by having Bob "ping" Alice > over an encrypted message to ensure Alice can decrypt, prior to > sending actual message data? > This assumes Alice is online when Bob wants to talk to her, doesn't it? Which is an assumption this protocol wants to avoid. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA
On 31 March 2017 at 11:37, Daniel Gultsch wrote: > I think it is relatively fair to assume that a company or individual who > is able to create a Non-GPL implementation of the Double Ratchet will not > fail to do so just because of a missing XEdDSA implementation. I implemented ODR before it used X3DH, and I'm now blocked by XEdDSA. > If someone fails to implement XEdDSA they probably shouldn't implement > ODR. I'm pretty sure this is wrong. Apart from the practical fact that that would require forking many low-level primitives from crypto-libraries, I'm pretty sure asking protocol devs like me to combine those into their own crypto primitive is about as responsible as asking them to build a parachute for base jumping: there's a good chance it'll open, but I'm pretty sure there will be casualties. There's a reason this stuff is left to crypto professionals. cheers, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA
> This requires huge changes in all OMEMO implementations, and there are > quite few already: https://omemo.top > I count 4 implementations in an incomplete list of 40 clients. As far as I understand, clients already need to fork and patch libsignal to be compliant with OMEMO anyway. 3DH takes 4 lines of code (you can make it a one-liner if you want to), so that doesn't sound too bad? so I'm expecting independent implementations of the protocol pretty soon. > I would think the list of people interested in an open E2E chat protocol is limited, and one of them already has its own implementation. > there is no Olm library for java at the moment, so again there is a missing implementation. If OMEMO is a succesful, implementable protocol (instead of a wrapper around a library that only a very limited number of people can use), the argument of 'there is no code for this' will quickly be outdated. thanks, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA
Hi Florian, If I understood Remko correctly he is arguing that because there are no > non-GPL XEdDSA implementations OMEMO will probably not see any adoption. > That was worded a bit hyperbolically, sorry. I meant to say it won't see *wide* adoption. > And I think it shouldn't matter right now. In general, it's correct that the license of the main implementation of a XEP doesn't matter, as long as the XEP can be reasonably implemented without it. Implementing double ratchet yourself is reasonable; implementing your own crypto primitives is neither reasonable nor responsible. I see a few ways forward with this: 1. We go back to Olm's protocol of establishing an initial shared secret, using regular 3DH instead of X3DH. + Moves us back to an audited, implementable algorithm + No need to change existing identity keys - This weakens the forward secrecy. I don't know enough about it to understand the consequence. 2. We replace XEdDSA (the primitive on which X3DH relies) with EdDSA. + EdDSA signatures are available in several crypto libraries. + Ed25519 keys can be converted to X25519 keys, so the rest of the algorithm stays the same. - Identity keys need to be changed to Ed25519 private keys, so existing keys become invalid. - I only found 1 implementation for Ed25519 to X25519 key conversion in an established library, namely LibSodium (permissively licensed). Several other (permissively licensed) implementations exist in isolation. Not sure whether other established crypto libraries will follow and implement this. It's a simple primitive, so it might, but I don't know how these things go. - This part of the algorithm hasn't been audited. 3. We stay with XEdDSA (the primitive on which X3DH relies) + No need to change existing identity keys + This approach has been audited. - Currently, no permissible implementation exists (or I couldn't find one at least). It's not clear when or if this will ever happen, and whether it will become widespread across crypto libraries. I don't know how these things generally go. I have only seen an issue for this in the LibSodium tracker ( https://github.com/jedisct1/libsodium/issues/335 ) cheers, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA
Hi Andy, Thanks for responding! On 30 March 2017 at 15:10, Andreas Straub wrote: > You raise a valid point. I agree that this construction seems cleaner from > a purely theoretical standpoint. > Actually, it's the practical standpoint that worries me most, in that this is not practically implementable for non-GPL clients at the moment. Permissible implementations of XEdDSA may or may not emerge, but as long as it is not something available, you're taking a risk of making a standard that will never be adopted. (not even talking about things such as FIPS-certifiable, which I know even less about). Having to regenerate identity keys is a valid usability concern. I'm throwing the idea out there as an alternative, which has to be weighed against the alternative, given the availability of crypto algorithms for the approach to keep them, and bearing in mind the fact that we'll probably have to break compatibility with signal and previous OMEMO versions anyway. I agree that losing the audit is a downside, but I'm not sure if the alternative is realistic if you want your XEP to take off. Given the right choice of crypto primitives, implementing a library to do double ratchet itself doesn't sound that big of an undertaking (I did a prototype of the Olm version in C++ in an afternoon or 2, including getting my head around all this stuff). The bulk of the work lies in proper UIs for all this. thanks! Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA
Hi Daniel, On 30 March 2017 at 10:31, Daniel Gultsch wrote: > Are you looking for this: https://whispersystems.org/ > docs/specifications/xeddsa/ > No, I've seen the spec, thanks. I'm looking for implementations of it. This is low-level crypto, I would think you don't want to implement this yourself. cheers, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] OMEMO (XEP-0384) use of X3DH / XEdDSA
Hi, The upcoming version of the OMEMO XEP relies on X3DH for establishing an initial shared secret. In my extremely limited understanding of it, I'm wondering whether this is the best approach for OMEMO. X3DH relies on XEdDSA to be able to use Curve25519 keys to create EdDSA-signatures. As far as I can tell, this solved a problem where all long-standing identity keys in Signal were X25519, and they needed them to create signatures (which you can't do without conversion to Ed25519). I can't seem to find any public implementation of XEdDSA yet, except in libsignal, so this sounds like it makes implementing OMEMO pretty hard at the moment. On the other hand, the other way round (creating Curve25519 keys from Ed25519 keys) is apparently a simpler thing to do, and there *are* public implementations of this (e.g. https://download.libsodium.org/doc/advanced/ed25519-curve25519.html ) So, I'm wondering whether it wouldn't make more sense to not carry the Signal legacy around in OMEMO, use Ed25519 keys as identity keys, and adapt X3DH to use these for creating an initial shared secret (with the same properties). The rest of the protocol can stay the same, since these keys can be converted to Curve25519. But i'm way out of my depth here, so I might be talking gibberish. thanks, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO (XEP-0384) Crypto Questions/Remarks
Hi Andy, On 29 March 2017 at 16:49, Andreas Straub wrote: > to make a long story short, a new revision of the spec has been in the > works for quite a while now and I just submitted the draft.[1] It should > resolve all of these questions. > Another question that pops up: the envelope now contains the different message headers as XML attributes. However, these headers need to be authenticated by the AEAD algorithm. So, the entire header needs to be serialized so it can be passed to the AEAD algorithm, and it's not defined how this has to be done. cheers, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] OMEMO (XEP-0384) Crypto Questions/Remarks
Hi Andy, On 29 March 2017 at 16:49, Andreas Straub wrote: > to make a long story short, a new revision of the spec has been in the > works for quite a while now and I just submitted the draft.[1] It should > resolve all of these questions. > Great, thanks a lot! On first sight, my questions are indeed answered. Should AES-GCM be considered as an AEAD scheme instead of AES-CBC+HMAC? As far as I can tell, it is more convenient to use, and more efficient (but I'm no crypto expert, maybe there are other reasons against/for it). thanks, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] OMEMO (XEP-0384) Crypto Questions/Remarks
Hi, I have a few outstanding questions/remarks about the crypto protocol part of OMEMO: - The XEP says it uses the Olm protocol, but it also mentions signed pre-keys (which I assume are about X3DH, which Olm doesn't use). Either the X3DH bits should be removed, or we should document our 'fork' of the Olm protocol that uses X3DH. - Olm doesn't send the previous chain length with its messages. This makes it impossible to know whether or not there have been skipped message keys that need to be stored. Is this something we should add, is out-of-order messages something we don't need to deal with? Note that sending the previous chain length *is* part of the original Double Ratchet spec. - The XEP uses AES-128GCM for encryption of the payload. The payload itself is (I assume) an Olm encrypted message. Olm uses a combination of AES-CBC for encryption and HMAC-SHA256 for authentication. For consistency, can/should we replace the Olm encrypted message format with AES-GCM as well for both authentication and encryption? - Is there a specific reason for going with AES-128GCM instead of AES-256GCM? I'm asking for practical purposes, because some opinionated crypto libs such as NaCl and LibSodium only have the latter. Might be easier for implementations if AES-256GCM is taken. thanks, Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
Re: [Standards] XEP-0384 (OMEMO Encryption) Questions/Remarks
On 13 March 2017 at 09:39, VanitasVitae wrote: > The signed preKeys are used for authentication. > I understand this is the idea, but where is this described in the Olm/OMEMO protocol? AFAICT, this is an X3DH thing, which Olm doesn't use. > Deviceid collisions with own devices are not allowed (the newer device has > to generate a new Id in that case). In mucs it doesn't really matter, since > the receiving device can simply try to decrypt with every matching keyId In > the message. > I guessed this, but when it comes to crypto, I don't like to guess things, and prefer to see things explicitly stated in a XEP. Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] XEP-0384 (OMEMO Encryption) Questions/Remarks
Hi, I have a few questions/remarks about XEP-0384: - The examples mention signed pre-keys. This isn't part of the Olm protocol AFAICT, I only saw it in the original double ratchet spec. Is this a remnant of an older version of the XEP? Should this be dropped, or is the plan to use X3DH eventually? - The XEP uses AES128-GCM for encryption, which seems different from Olm (which uses AES256-CBC). I know very little about crypto, but is there a reason for going with AES128 instead of AES256? I'm asking, because on first sight, it seemed easier to find support for AES256-GCM (e.g. in libsodium/nacl) than for AES128-GCM. - I can't find a reference in the XEP on how the ratchet algorithm works in multi-user settings (there's only a reference to Olm, which AFAICT only works for single users). Is this where megaolm steps in? Should there be a reference to a protocol? - The Device ID being a randomly generated 32-bit integer seems out of the ordinary? Not that the chances of collisions in a big MUC are *that* big, but would a GUID be more consistent with some previous XEPs? Should something be said about what to do when recipient device IDs collide? - Cosmetic: camel case is used for tags/attributes, whereas I believe kebab-case is more consistent with other XEPs? thanks! Remko ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] Missing PubSub attribute
Hi all, The XEP-0060 schema seems to be missing an attribute. Example 30 uses the 'node' attribute on the element in the pubsub namespace (which is consistent with the other queries), but it doesn't seem to be present in Schema 17.1. I think it should have: cheers, Remko
Re: [Standards] Account Management protoXEP
> If it's a well-defined FORM_TYPE, a client could do something fancy for the
> well-defined fields (e.g. {urn:xmpp:acct-mgmt:0:dataforms:update}newpass gets
> a special strength meter nearby), and an "advanced" button/tab/overlay/etc
> for the non-standard things.
Right, but I always found this to be a cop-out. Either you want ad-hoc
protocols, and you don't need FORM_TYPES, or you want the client to
know about a command, and then you need a real protocol.
cheers,
Remko
Re: [Standards] Account Management protoXEP
> For both account management and registration, using the ad-hoc framework > seems most sensible - it would allow us maximum flexibility as well as > near-instant deployment. I don't think registration fits the ad-hoc use case, because it is a special action outside of the general session flow, which means you can't rely on it being accessed from the generic "Execute ad-hoc command" functionality of a client. That's why i think such a thing should probably get a dedicated protocol (on top of data forms). That said, I agree with Kurt that the need for in-band registration is probably not very high, because of typical out-of-band registrations these days. So I'm also inclined to suggest to develop a XEP for account management without registration, and possibly base it on ad-hoc commands. Putting account management in ad-hoc commands means that we don't expect clients to have a "Change password" button, but instead go through the server provided "Change account settings" dialog. It takes away power from the client (it won't be able to add fancy things like password strength measurers), but it gives more power to the server to provide a UI (e.g. instructions) that fit it, and it saves client development time :-) cheers, Remko
Re: [Standards] LAST CALL: XEP-0260 (Jingle SOCKS5 Bytestreams Transport Method)
I would also point out Tobias' request for clarification about the DST.ADDR computation: http://mail.jabber.org/pipermail/jingle/2011-August/001705.html
Re: [Standards] RTT: no negotiation of the feature
Hi Mark, On Fri, Jun 24, 2011 at 5:15 PM, Mark Rejhon wrote: > The earlier spec covered feature negotiation via XEP-0020. However, it was > encouraged by a few people that spec simplification became more important, > and to focus chiefly on the most basic, core interop issues, at least for > the first published version of the specification. How about just using Disco/Caps discovery for now, as was suggested earlier? I think this will make most people happy, and will only add a few lines to the spec. See for example XEP-0085, section 4: http://xmpp.org/extensions/xep-0085.html cheers, Remko
Re: [Standards] RTT, take 2
> So I'd say that we should refer to characters in a string, and deal with > Unicode code-points in the abstract. I'm wondering whether 'code points' are any better than UTF-8 based positioning. Isn't it possible that a codepoint position also points inside a character/glyph/...? Peter could probably shed some light on this. The major problem is that you want something that you can tell your GUI "remove N characters", but that such an operation is very toolkit-specific and not well specified, and that you don't have any control over this. For example, in Qt, this would most likely be implemented using a QTextCursor ( http://doc.trolltech.com/4.7/qtextcursor.html ). However, the text talks about 'positioning at character X', and it doesn't seem to be defined what this means. I think that deleting one 'character' using this API would potentially delete multiple unicode code points? (or maybe i don't know enough about unicode). But if my understanding is correct, then i'm not sure if such a positioning-based API would ever work in practice (for multiple implementations). cheers, Remko
Re: [Standards] RTT, take 2
[ I don't like writing me-too e-mails, but you beat me by a minute to sending the exact same mail, so I'm doing it anyway ;-) ] > So I'd say that we should refer to characters in a string, and deal with > Unicode code-points in the abstract. I'd expect that implementations would > convert this internally into whatever made sense for them. I think it would be the first protocol to depend on knowing how to count code points (I haven't needed it before), but I also think it's the only sensible thing to do, because you could end up with incorrect encodings using the protocol otherwise. Anyway, for applications that don't use Unicode libraries, rolling your own codepoint count isn't very hard, at least for utf-8. cheers, Remko
Re: [Standards] hash agility in file transfer
> They're lowercase. > The usual way that IANA names differ from other names is that IANA always > hash the hyphen in SHA names Ok then, even better :) One drawback of approach 2 and the agreement that all iana hash names are ok as elements is the potential clash between hash names and element names in the namespace of the protocol using the hashes. It's unlikely that Jingle will ever have an element 'sha-1', but still, theoretically ... cheers, Remko
Re: [Standards] hash agility in file transfer
> "I support Jingle FT with universal hashing, and I support Foo with > universal hashing, and the hashes I support are X, Y, and Z, with a > preference for Z." > > Or do we want to say: > > "I support Jingle FT with hashes X, Y, and Z. I support Foo with Y, and Z." I think 99% will want to say 1, but I think we have to go with 2 in case someone doesn't. Ash I think that supporting 2 is enough, no? (1 would only be convenience, but it's easy enough to programatically add all hashes you support for every feature that supports hashes?) And as element names: the IANA hash names are all upper case, right? Can we get by by agreeing we use the lowercase version of the IANA names as element names? cheers, Remko
Re: [Standards] RFC vs privacy lists
> I thought we had established "incoming" means incoming from the client's > POV. Right, i actually meant the whole chain, up to and including the server part (up to the stanza router). It doesn't make sense to filter out stanzas from your own server (not talking about the ones from other users on your server). But the XEP could use some more specification of what "incoming" really is to avoid this problem of shooting yourself in the foot. But anyway, as Dave mentioned, there's a reason why this XEP was pulled out of the RFC, and why there are XEPs that supersede the functionality of this one. I would stay away from privacy lists ;-) cheers, Remko
Re: [Standards] RFC vs privacy lists
> under 'incoming IQ requests' for 2 reasons: they're not 'incoming' , > and they're not 'requests'. I take one of both back, since the XEP talks about IQ stanzas, not requests. The conclusion remains the same, though: the server should not block them ;-) cheers, Remko
Re: [Standards] RFC vs privacy lists
> If you block all incommig IQs ALL of them are going to be blocked, including > the ones from your server. This doesn't sound right to me. IQ responses from your server (e.g. disco#info) should not be blocked by your server, as these do not fall under 'incoming IQ requests' for 2 reasons: they're not 'incoming' , and they're not 'requests'. cheers, Remko
Re: [Standards] RFC vs privacy lists
> So a client is not allowed to send an iq to its server if this anti-spam > rule is set? I'm not quite following why it's not ok to send an iq to your own server? The XEP says that privacy lists block *incoming* IQs (that is, 'incoming' from the point of view of the client, so from other entities on the network than your client). It should be ok to send IQ requests to anywhere you like. If your server blocks IQs you are sending, something sounds wrong with that server (as this is about *outgoing* IQs). And it's even worse if it's blocking outgoing IQs to the server *itself* (like disco#info). cheers, Remko
Re: [Standards] RFC vs privacy lists
> If a user setup this rule it's because he doesn't want spam. And if server > don't block result|error, user can be spammed of iq result for ex According to xep-0016: " The allowable child elements are: -- blocks incoming message stanzas -- blocks incoming IQ stanzas -- blocks incoming presence notifications -- blocks outgoing presence notifications" So, privacy lists is only about incoming IQ, and assumes that the client will not send outgoing IQs to contacts it's blocking (which assumes the client knows the semantics about privacy lists). cheers, Remko
Re: [Standards] RFC vs privacy lists
> XEP 16 (copied from the RFC), section 2.14 says that the server should > return service-unavailable. And by 'should', i mean MUST. cheers, Remko
Re: [Standards] RFC vs privacy lists
> That's normal because RFC [1] says that "Privacy lists MUST be the first > delivery rule applied by a server, superseding ..." XEP 16 (copied from the RFC), section 2.14 says that the server should return service-unavailable. cheers, Remko
Re: [Standards] Correcting last message
> We thought like you before, but we had to listen to our users. I wasn't saying you shouldn't put limits in your implementation; i was just saying i wouldn't put it in the protocol: not every XMPP application works like yours. Hence the recommendation. > How can we prevent this? (because we must prevent this... do you disagree?) You don't. You just say "This message has been edited", and assume people will not do silly things like this :-) Some clients can be smart and strike out parts of a conversation and replace them with other parts; it would be quite obvious that the message has changed in significant ways. Or, if you feel like a limitation is the only way of solving the problem, put in a limitation. Just don't force limits upon clients that can do fine without them. cheers, Remko
Re: [Standards] Correcting last message
> Only the latest message seems overly restrictive (especially if the last > message you send it "oops"). I'd say a buffer of, say, the last 5 > messages might be appropriate. For the same reason, I think that only one edit is overly restrictive. I have needed several edits to get a one-sentence IM message right :-) I don't see a reason to put in arbitrary restrictions in the protocol (different use cases can warrant different limits); i wouldn't mind recommendations, though. As long as the client indicates that a message has been edited X times (and provides the original message), i don't really see any issues. cheers, Remko
Re: [Standards] XEP-0198 status
On Sat, Feb 12, 2011 at 2:20 PM, Peter Saint-Andre wrote: > On 2/12/11 5:09 AM, Remko Tronçon wrote: > "It" = IPv6? We might need it soon. ;-) "It" = parsing RFC3986 rules. We do support IPv6 ;-) cheers, Remko
Re: [Standards] XEP-0198 status
Hi Ben, > I think using RFC3986 (2732) formatting rules for supporting IPv6 > address/port in a single attribute would be fine. Any software that intends > to communicate over IPv6 is probably going to need to understand that format > at some point. Well, we haven't needed it so far, and this XEP would be the first time we do, but I may be missing something. That's why I'm also in favor of splitting it into a separate attribute. cheers, Remko
Re: [Standards] [Summit] proposed topics
> Here's a rough list of clusters, in no particular order: Sounds like an interesting summit, looking forward to your talk on i18n. I'm in favor of Knowing the topics in advance btw, i think it'll make the summit a bit less chaotic than last years ;) Cheers, Remko
Re: [Standards] XEP-0184 1.1rc7
> Done: Looks good to me! cheers, Remko
Re: [Standards] XEP-0184 1.1rc7
> As each message is in a stream with a particular direction Well, not really. Clients usually generate IDs based on some simple algorithm, and don't take into account IDs from incoming messages. For example, 2 clients with a simple incrementing counter would give this: C1->C2: (id=1) hi there C2->C1: (id=1) hello C1->C2: (id=1) C1 sent two normal messages with id=1: the first one generated from the auto-incrementing number algorithm, the second one mirroring the message from the incoming message. > There has been a trend to remove batch features from specifications > lately, like in XEP-0060 (Publish-Subscribe). I don't think we should > introduce new ones. I agree. cheers, Remko
[Standards] XEP-0184 1.1rc7
Hi, Something still feels weird about the latest version of XEP 184. When sending back a receipt, the id of the message must mirror the id of the incoming message. So far, I always thought that id's were unique to the sender domain, except when the stanza is of type 'error' (or type 'result' for iq). Aren't there risks when normal messages suddenly get ids from another domain (potentially causing conflicts?) I was expecting the id to be a part of the received, as in This could potentially also allow sending a batch of receipts in one message (if we would want that) cheers, Remko
Re: [Standards] XEP-0048 bookmarks
> I think the sensible thing for clients to do is to use 223 if it's > available, and fall back to 49 if it's not. And, if 223 is available but contains no data, to check 49 anyway (in case the server upgraded and supports 223, and you want to transfer your bookmarks)? Or do we assume that servers upgrading to 223 always migrate their 49 data too? (if so, shouldn't this be in the xep?) cheers, Remko
Re: [Standards] NEW: XEP-0279 (Server IP Check)
> The clean separation of RFC 3920 and RFC 3921 allows this. > XEP-0279 breaks this and causes tight coupling of these layers. On the other hand, if your server implementation has a hard time figuring it out, don't support it. If all the stories are true, this XEP is a use case that will only be used in limited scenarios anyway (since all of our popular scenarios support more advanced features that don't require this). cheers, Remko
Re: [Standards] PDFs!
> from http://xmpp.org/extensions/xep-0012.pdf in your editor you have > different line breaking as you see in the PDF? No, i means that I get spaces in between characters. Copy pastng from Preview (OS X) gives me: < i q f r o m = ’ r o m e o @ m o n t a g u e . n e t / o r c h a r d ’ i d = ’ l a s t 1 ’ t o = ’ j u l i e t @ c a p u l e t . c o m ’ t y p e = ’ g e t ’ > < q u e r y x m l n s = ’ j a b b e r : i q : l a s t ’ / > < / i q > Oddly enough, this is slightly different than copy pasting from Adobe Reader (OS X): < iq from = ’ r o m e o @ m o n t a g u e . net / o r c h a r d ’ id = ’ last1 ’ to = ’ j u l i e t @ c a p u l e t . com ’ type = ’ get ’ > < query xmlns = ’ j a b b e r : i q : l a s t ’/ > Notice how the XML attribute names and tags don't have spaces between the characters. cheers, Remko
Re: [Standards] PDFs!
> I hope it meets your high font standards. :P Just checked the PDF. Inconsolata is no TheSansMonoCd (it feels a bit too loose to my taste), but I'm willing to shut up about it now. The copy pasting is still a bit off, but I'm sure you're working hard to fix that as we speak :) thanks! Remko
Re: [Standards] PDFs!
> XML source in the PDFs is now(might take some minutes until all XEPs are > rebuild) using a mono spaced typeface. In our case it's in > Inconsolata, http://www.levien.com/type/myfonts/inconsolata.html . I hope it > meets your high font standards. :P I like Inconsolata, but never used it because it was lacking a bold and italic variant. But our XEPs don't use that (yet), so it sounds like a fine choice to me ;-) cheers, Remko
Re: [Standards] PDFs!
> So highlighting should work for all XEP htmls now. They HTML files are > rebuild right now. Looking good. Adding a border around the examples unfortunately reveals that we always have trailing whitespace at the end of the verbatim XMPP stanzas (to make the XML sources look prettier). It would be good if we had a transformation that removes trailing whitespaces from examples and/or verbatim blocks. cheers, Remko
Re: [Standards] PDFs!
> We're still working out a few glitches here and there, so your feedback > is appreciated. Cool. Something seems wrong with the example stanzas, though: there's too much space between the characters, making the examples less readable. Perhaps a bad font selection, or forcing fixed with on a proportional font? Also, copy pasting inserts spaces between the characters, maybe that's related. cheers, Remko
Re: [Standards] Action rules in XEP-0050
> There are less horrible scenarios, too. Good point. cheers, Remko
Re: [Standards] Action rules in XEP-0050
> Yep, which are the same actions, confusing users. No, they're not, which was the point of my rant. "Next" gets you on to more advanced settings, whereas "Finish" just says "Skip the next screens, the defaults are fine for me". cheers, Remko
Re: [Standards] Action rules in XEP-0050
> Is that kind of structure commonly used for short-cuts in wizards, and > suchlike? Unfortunately, it is. Horrible UI: there's no way of knowing what is behind 'next' unless you press it, so you basically have to press it anyway (unless you know your way around the wizard like a pro, and remember by heart, which probably means you don't use a wizard ;-)) But since it's a used technique, i think we shoudl support it. cheers, Remko
