Mridul Muralidharan wrote:
Joe Hildebrand wrote:
On Jun 27, 2007, at 2:32 AM, Jacek Konieczny wrote:
That is not true. Years ago I have proposed other solution: instead of
announcing client name version and caps clients should announce digest
(e.g. MD5 or SHA) of normalized set of supported features. The list
would have to be obtained only once per feature set and it could be
verified. The traffic would not be much bigger than with current
solution and the 'cache taint' problem would be gone. And
implementations could be simpler (no need for capability registry --
namespace registry is enough) and less error-prone (when a new namespace
is added the digest would change 'automatically'. Currently developers
have to manually update version or capability string).
I think the digest could be used with current specification too -- as
the only capability string, bound with all the supported namespaces. But
XEP-0115 is not optimized for such usage and says nothing about digest
verification.
The current spec could absolutely be used for this. The hardest part
is spec'ing how to generate a string that has all of the capabilities,
so that you can run the hash. Canonical XML is massive overkill, but,
for example, if we just said:
- For all sorting, use the Unicode Collation Algorithm
(http://www.unicode.org/unicode/reports/tr10/)
- Initialize an empty string E
- sort the identities by category, then type
- for each identity, append the category, then the type (if it exists)
to E (note: any information inside an identity will be ignored)
- sort the features by URI
- for each feature, append the URI to E (note: any information inside
a feature will be ignored)
- calculate the MD5 sum for E
- use this for the version number or extension name
Example (adapted from XEP-115, example 2):
<presence from='[EMAIL PROTECTED]/home'>
<c xmlns='http://jabber.org/protocol/caps'
node='http://exodus.jabberstudio.org/caps'
ver='730c80b442e150dd5e19a31f8edfa8b1'
ext='d6224a352df544cfde1fbce177301c67
d0ef9e8327acf5873d16fe083b4d3f3f'/>
</presence>
The receiving client SHOULD check the hashes, after doing the IQ/gets:
md5(clientpchttp://jabber.org/protocol/disco#infohttp://jabber.org/protocol/disco#itemshttp://jabber.org/protocol/feature-neghttp://jabber.org/protocol/muc)
= 730c80b442e150dd5e19a31f8edfa8b1
md5(clientpchttp://jabber.org/protocol/bytestreamshttp://jabber.org/protocol/sihttp://jabber.org/protocol/si/profile/file-transfer)
= d6224a352df544cfde1fbce177301c67
md5(clientpchttp://jabber.org/protocol/xhtml-im) =
d0ef9e8327acf5873d16fe083b4d3f3f
If the receiving client detects an inconsistency, it MUST NOT use the
information it received, and SHOULD show an error of some kind.
For backwards-compatibility, any version number that is not 32 octets
long consisting only of [0-9a-f] MUST be treated as if it does not
implement MD5 checking.
Analysis:
- Existing entities, both sending and receiving, should work fine
- Over time, we can phase in entities that send md5 versions and ext's
- Receiving clients that care about security can start checking MD5
+1
This sounds good enough to prevent polluting the client side cache.
Forgot to add, change name from ver & ext to verh and exth ?
Also, relationship between caps and pep :
If the server supports pep - then cant it not directly respond back to
the requester for caps disco queries ?
Regards,
Mridul
hashes of the features to check for poisoning.
- Downside: more bytes in presence than today.
With server optimization implemented, wont this not be restricted to
first time presence push to a contact ?
So maybe not as bad ?
- Assertion: anything else we do will be at least this bad if not worse.
yes
If we add these bits to -115, will everyone agree to never bring up
changing caps again, and to all agree on that the next time a n00b
comes around?
heh
--Joe Hildebrand
Regards,
Mridul
