On Wed, Sep 23, 2009 at 3:04 AM, Peter Saint-Andre <[email protected]>wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > XEP-0030 allows the 'category' and 'type' attributes to have any length, > including zero. This opens the door to certain attacks in entity > capabilities (see the recent discussion on the [email protected] list) > and in any case I think it is not a good idea (is there any meaning to a > zero-length category or type?). Also, we need to harmonize the 'jid' > attribute in disco with rfc3920bis. I propose the following: > > 1. 'category' shall have a minimum length of 1 > > 2. 'type' shall have a minimum length of 1 > > 3. 'jid' shall be a length between 1 and 3071 (see 3920bis) > > Peter > > - -- > Peter Saint-Andre > https://stpeter.im/ > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkq5SdMACgkQNL8k5A2w/vx+nQCgsIQ5LAYHoUQ14dtCrf6mbVG/ > shcAnj+i73sM80zRVUIrD5MkPJeiR6yG > =FAvy > -----END PGP SIGNATURE----- > Quoting from one of my messages on the security list: <feature var='http://jabber.org/protocol/muc'/> can still be replaced by <identity category='http:' type='/jabber.org' xml:lang='protocol' name='muc'/> which can be replaced by <identity category='http:/' type='jabber.org' xml:lang='protocol' name='muc'/> Therefore, the security benefit of requiring minimum lengths is questionable. In its current form, the hashing function always succeeds for any given non-null input. This is desirable because it simplifies implementations, and is exactly the same as popular hashing functions (MD5, SHA, etc). Specifying minimum lengths is fine, but is there a reason for receiving implementations to actually enforce these limits? The caps algorithm in XEP-0115 actually talks about missing 'type' attributes. This ought to be fixed. -- Waqas Hussain
