[Standards] UPDATED: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)
Version 0.6.0 of XEP-0300 (Use of Cryptographic Hash Functions in XMPP) has been released. Abstract: This document provides a common wire format for the transport of cryptographic hash function references and hash function values in XMPP protocol extensions. Changelog: Remove hash function recommendations to be able to advance this without tying down the recommendations. Recommendations are now in XEP-0414. (jsc) URL: https://xmpp.org/extensions/xep-0300.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)
Version 0.5.3 of XEP-0300 (Use of Cryptographic Hash Functions in XMPP) has been released. Abstract: This document provides recommendations for the use of cryptographic hash functions in XMPP protocol extensions. Changelog: Clarify textual content of the element. (fs) URL: https://xmpp.org/extensions/xep-0300.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date. ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)
Version 0.5.2 of XEP-0300 (Use of Cryptographic Hash Functions in XMPP) has been released. Abstract: This document provides recommendations for the use of cryptographic hash functions in XMPP protocol extensions. Changelog: Add hash-used element (ps) URL: https://xmpp.org/extensions/xep-0300.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)
Version 0.5.1 of XEP-0300 (Use of Cryptographic Hash Functions in XMPP) has been released. Abstract: This document provides recommendations for the use of cryptographic hash functions in XMPP protocol extensions. Changelog: Use xs:base64Binary instead of xs:string in the schema (fs) Diff: https://xmpp.org/extensions/diff/api/xep/0300/diff/0.5/vs/0.5.1 URL: https://xmpp.org/extensions/xep-0300.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)
Version 0.5 of XEP-0300 (Use of Cryptographic Hash Functions in XMPP) has been released. Abstract: This document provides recommendations for the use of cryptographic hash functions in XMPP protocol extensions. Changelog: Explicitly specify encoding format. Namespace version bump to urn:xmpp:hashes:2. (tobias) Diff: http://xmpp.org/extensions/diff/api/xep/0300/diff/0.4/vs/0.5 URL: http://xmpp.org/extensions/xep-0300.html ___ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org ___
[Standards] UPDATED: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)
Version 0.3 of XEP-0300 (Use of Cryptographic Hash Functions in XMPP) has been released. Abstract: This document provides recommendations for the use of cryptographic hash functions in XMPP protocol extensions. Changelog: Modified XML structure to remove wrapper element; added recommendations for new XMPP extensions; softened recommendations for existing extensions. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0300/diff/0.2/vs/0.3 URL: http://xmpp.org/extensions/xep-0300.html
Re: [Standards] UPDATED: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)
On 2/8/12 10:12 AM, XMPP Extensions Editor wrote: Version 0.3 of XEP-0300 (Use of Cryptographic Hash Functions in XMPP) has been released. Abstract: This document provides recommendations for the use of cryptographic hash functions in XMPP protocol extensions. Changelog: Modified XML structure to remove wrapper element; added recommendations for new XMPP extensions; softened recommendations for existing extensions. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0300/diff/0.2/vs/0.3 URL: http://xmpp.org/extensions/xep-0300.html This version incorporates feedback from Waqas Hussain. Kev and Matthew, please check this as co-authors to make sure that you think we're on the right track. Peter -- Peter Saint-Andre https://stpeter.im/
Re: [Standards] UPDATED: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)
Waqas, I've incorporated all of your feedback into the spec, and will check it with my co-authors here at the XMPP Summit before pushing out a revision. On Fri, Dec 09, 2011 at 01:38:12AM +0500, Waqas Hussain wrote: On Tue, Dec 6, 2011 at 3:32 AM, Peter Saint-Andre stpe...@stpeter.im wrote: On 12/5/11 3:16 PM, XMPP Extensions Editor wrote: Version 0.2 of XEP-0300 (Use of Cryptographic Hash Functions in XMPP) has been released. Abstract: This document provides recommendations for the use of cryptographic hash functions in XMPP protocol extensions. Changelog: Updated to reflect initial analysis of existing XMPP protocol extensions. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0300/diff/0.1/vs/0.2 URL: http://xmpp.org/extensions/xep-0300.html Folks, I started to look at XEP-0300 in relation to existing extensions. Please review my work so far, and do your own thinking about how useful (or not useful) XEP-0300 is. I'm curious about the descriptive feature namespaces (urn:xmpp:hash-function-textual-names:md5)... I'm sure there is something behind not using urn:xmpp:hash:md5, or similar :) Also, the encapsulating hashes xmlns='urn:xmpp:hashes:0'/ element isn't really necessary, except for cases where only a single element is allowed (pubsub). I recall we were measuring bytes when defining entity caps in presence, which would suggest changing this protocol to more compact. A consistent approach to hashes is a good thing. Changing widely deployed protocols is a bad thing. The nature of the XEP makes it awkward to use in many protocols (as noted at the end of this message). I'm -0 on this XEP. Of the XEPs listed in XEP-0300 section 4.5, the widely deployed protocols are entity caps, vcard based avatars, and socks5 bytestreams. BOSH is widely deployed, but I don't think the hashing part is. I'd suggest leaving vCard based avatars alone. Entity caps is arguably supposed to change, due to security issues. I'm not sure about the SOCKS5 XEPs. They are quite widely deployed, and if we do change things, backwards compatibility will need to be kept. That said, changing things in these various protocols would be fairly awkward, given the existing use of attributes for hashes. e.g., it would be fairly awkward to change the BOSH 'key' and 'newkey' attribute to elements in body/. -- Waqas Hussain --
Re: [Standards] UPDATED: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)
On Tue, Dec 6, 2011 at 3:32 AM, Peter Saint-Andre stpe...@stpeter.im wrote: On 12/5/11 3:16 PM, XMPP Extensions Editor wrote: Version 0.2 of XEP-0300 (Use of Cryptographic Hash Functions in XMPP) has been released. Abstract: This document provides recommendations for the use of cryptographic hash functions in XMPP protocol extensions. Changelog: Updated to reflect initial analysis of existing XMPP protocol extensions. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0300/diff/0.1/vs/0.2 URL: http://xmpp.org/extensions/xep-0300.html Folks, I started to look at XEP-0300 in relation to existing extensions. Please review my work so far, and do your own thinking about how useful (or not useful) XEP-0300 is. I'm curious about the descriptive feature namespaces (urn:xmpp:hash-function-textual-names:md5)... I'm sure there is something behind not using urn:xmpp:hash:md5, or similar :) Also, the encapsulating hashes xmlns='urn:xmpp:hashes:0'/ element isn't really necessary, except for cases where only a single element is allowed (pubsub). I recall we were measuring bytes when defining entity caps in presence, which would suggest changing this protocol to more compact. A consistent approach to hashes is a good thing. Changing widely deployed protocols is a bad thing. The nature of the XEP makes it awkward to use in many protocols (as noted at the end of this message). I'm -0 on this XEP. Of the XEPs listed in XEP-0300 section 4.5, the widely deployed protocols are entity caps, vcard based avatars, and socks5 bytestreams. BOSH is widely deployed, but I don't think the hashing part is. I'd suggest leaving vCard based avatars alone. Entity caps is arguably supposed to change, due to security issues. I'm not sure about the SOCKS5 XEPs. They are quite widely deployed, and if we do change things, backwards compatibility will need to be kept. That said, changing things in these various protocols would be fairly awkward, given the existing use of attributes for hashes. e.g., it would be fairly awkward to change the BOSH 'key' and 'newkey' attribute to elements in body/. -- Waqas Hussain
Re: [Standards] UPDATED: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)
Well, I think the problem that xep-300 pretends to fix, can easily be fixed by changing the XEPs that make use of hashes. If a XEP is using a hash algorithm that has been deprecated or is insecure, that XEP should be updated to mandate the discontinuation of such algorithm in clients. Hash algorithms don't deprecated as often, and using XEP-0300 would lead to a slower adoption of newer hash algo. For example: Client A sends file to Client B Client B is updated to use the most secure hash available Client A has a deprecated version of the hash Client B negotiates using XEP-300 and ends up using the less secure hash File transfer is successful This case would lead to a slower adoption of more secure technology. A negotiation makes sense in a lot of cases, for IBB or Socks5. But negotiating for hashes makes no sense because the implementation is as easy as changing a couple of lines of code. That's why it should be mandated to use the most secure and updated algorithm, and as I said, hashes don't deprecate frequently so that approach would be less inconvenient than xep-300. Now, I understand that there might be some ambiguity on which hashes are being use. I personally think that the attribute hash should never be used, instead md5 or sha1 should be used. P.S: I realized half way through that XEP-0300 is not negotiating, but instead is discovering support of hashes of the clients. Still, my point stands. It doesn't change anything. On Mon, Dec 5, 2011 at 5:32 PM, Peter Saint-Andre stpe...@stpeter.im wrote: On 12/5/11 3:16 PM, XMPP Extensions Editor wrote: Version 0.2 of XEP-0300 (Use of Cryptographic Hash Functions in XMPP) has been released. Abstract: This document provides recommendations for the use of cryptographic hash functions in XMPP protocol extensions. Changelog: Updated to reflect initial analysis of existing XMPP protocol extensions. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0300/diff/0.1/vs/0.2 URL: http://xmpp.org/extensions/xep-0300.html Folks, I started to look at XEP-0300 in relation to existing extensions. Please review my work so far, and do your own thinking about how useful (or not useful) XEP-0300 is. Peter -- Peter Saint-Andre https://stpeter.im/ -- Jefry Lagrange
Re: [Standards] UPDATED: XEP-0300 (Use of Cryptographic Hash Functions in XMPP)
On 12/5/11 3:16 PM, XMPP Extensions Editor wrote: Version 0.2 of XEP-0300 (Use of Cryptographic Hash Functions in XMPP) has been released. Abstract: This document provides recommendations for the use of cryptographic hash functions in XMPP protocol extensions. Changelog: Updated to reflect initial analysis of existing XMPP protocol extensions. (psa) Diff: http://xmpp.org/extensions/diff/api/xep/0300/diff/0.1/vs/0.2 URL: http://xmpp.org/extensions/xep-0300.html Folks, I started to look at XEP-0300 in relation to existing extensions. Please review my work so far, and do your own thinking about how useful (or not useful) XEP-0300 is. Peter -- Peter Saint-Andre https://stpeter.im/
