[Standards] Security implications of entity capabilities

Greg Hudson ghudson at MIT.EDU
Fri Mar 16 18:28:16 UTC 2007


I am a bit concerned by the ability of one malicious client to poison
the entity capability caches of other people's clients.  XEP-115
considers this possibility:

  It is possible (though unlikely) for a bad actor or rogue
  application to poison other entities by providing incorrect
  information in response to disco#info requests. To guard against
  such poisoning, a requesting entity MAY send disco#info requests to
  multiple entities that match the same node/ver or node/ext
  combination and then compare the results to ensure consistency. The
  requesting entity SHOULD NOT send the same request to more than five
  entities and MUST ensure that the entities are truly different by
  not sending the same request to multiple entities for which the
  <user at host> portion matches.

I suspect most implementations will simply cache the first response
they get.  If, for instance, e2e encryption is advertised by a
capability, it will be relatively straightforward to induce two nodes
to avoid e2e encryption when they would otherwise use it, by
advertising that a particular node/ver or node/ext combination does
not support that feature.

Perhaps the right answer is simply "don't use caps for
security-sensitive features like e2e encryption."  But it can be hard
to determine in advance what's security-sensitive sometimes.



More information about the Standards mailing list