[Standards] vcard-temp security considerations

Philipp Hancke fippo at goodadvice.pages.de
Thu Aug 8 19:54:35 UTC 2013


Am 08.08.2013 20:38, schrieb Dave Cridland:
> On Thu, Aug 8, 2013 at 2:06 PM, Philipp Hancke <fippo at goodadvice.pages.de>wrote:
>
>> The security considerations of 0054 currently say the vcard is public.
>>
>> I'd like to have additional text there along the lines of xep-0030 for a
>> more restrictive server:
>>    In response to a vcard-temp request, the server MUST return a
>>    <service-unavailable/> error if one of the following is true:
>>    1.  The target entity does not exist
>>    2. The requesting entity is not authorized to receive presence from the
>>       target entity (i.e., via a presence subscription of type "both" or
>>       "from") or is not otherwise trusted (e.g., another server in a
>>       trusted network).
>>    3. The requesting entity and at least one of the users resources have
>>      exchanged directed presence
>>
>> The last item is basically there not to break MUC. It might be good to add
>> this to 0030, too. But I can be convinced that this is already covered by
>> (2), even though not explicitly mentioned.
>>
>> Thoughts?
>>
>
> I think those are reasonable suggestions, but they're not a mandatory
> requirement in my opinion.

Point. It's an alternative behaviour. So the text should start with 
"Alternatively, a server MAY return..."

> I think we might offer it as a potential (and allowable) mitigation,
> though, alongside providing different vCards to different requestors, and
> so on.

Yes.

btw: returning <item-not-found/> instead of <service-unavailable/> when 
there is no vcard seems like a bad idea from the "don't allow account 
enumeration" POV. It seems this Peter missed that in the 2008 update and 
in 2003 this was not a concern.




More information about the Standards mailing list