Re: [Standards] vcard-temp security considerations
Am 08.08.2013 20:38, schrieb Dave Cridland: On Thu, Aug 8, 2013 at 2:06 PM, Philipp Hancke 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 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 instead of 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.
Re: [Standards] vcard-temp security considerations
On Thu, Aug 8, 2013 at 2:06 PM, Philipp Hancke 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 >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. I think we might offer it as a potential (and allowable) mitigation, though, alongside providing different vCards to different requestors, and so on.
[Standards] vcard-temp security considerations
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 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?
Re: [Standards] Application-level delivery notification between server and client
On Thu, Aug 8, 2013 at 10:44 AM, Daniele Ricci wrote: > p.s. the last paragraph came 3 times. > > Ah, sorry. It's very irritating when then happens.
Re: [Standards] Application-level delivery notification between server and client
Hi Dave, thanks for your delightful answer. Actually I was going to reply with pretty much the same arguments, I was looking for the time to write that... you saved me from a long writing :-) Anyway Dave has perfectly catched my needs. Although I ended up defining my own extension, I really would like to standardize it or (if possible) use an existing XEP. p.s. the last paragraph came 3 times. On Thu, Aug 8, 2013 at 11:37 AM, Dave Cridland wrote: > I know this thread is going to sleep, but I'd like to stick my oar in. :-) > > On Tue, Aug 6, 2013 at 9:15 PM, Daniele Ricci > wrote: >> >> Please correct me if I'm wrong at any point, just to be sure I >> understand XEP 198 and how I can use it in the right way. >> > > XEP-0198 is designed to make a stream: > - Reliable: You know what has definitely been received by the peer. > - Recoverable: You can have a stream span TCP connections, in effect, > without duplication or loss. > > But note this *only* has an effect for streams; "chat sessions" span > multiple streams - unless you're talking to a server, or using XEP-0174 > (Serverless messaging, in case I've got the number wrong) - and so all this > is doing is making each leg of the journey reliable. That's important, but > not sufficient. > >> >> In my case, I can only use the 'h' attribute to store the server-side >> message ID. Which I can't do according to the spec. >> > > Right - h is purely a count. Because it's only one stream, rather than > end-to-end, we can do this, and it's sufficient. We could have had and > contain random guids or something, but then people would have expected > to be able to insert semantic meaning into them, and they don't need that. > is the conversational equivalent of saying "Right?" at the end of a > sentence, and is the equivalent of saying "Uh-huh" and nodding > politely. You don't need to figure out which sentences have been received, > because it's just "everything up until this point". > > But just like a conversation where one side is just grunting and nodding, > while you know they've heard, you don't know if there was anything more. > >> >> But the biggest and main issue is: a receipt is actually part of a >> message. It's not stream management; it means Alice will receive a >> delivery receipt when message has been delivered (and acknowledged) by >> Bob. I can't just throw off at any time for this purpose - it >> would not be stream management any more. That's why I think I need >> something half XEP 198 and half XEP 194. >> > > And you're right - except you don't want half '198 and half '184, you > actually want all of both. > > Whilst XEP-0198 makes streams reliable, to make chat sessions reliable to > need XEP-0184, which will then mean you can reliably send a message - and > reliably get a receipt back when it's delivered. > > The reason you need both, despite them looking superficially similar, is > that without any XEP-0198 in place you can't actually tell if it was the > message that was lost or the XEP-0184 receipt, and so while the safe thing > to do is warn the user and possibly resend, that may be very irritating for > the recipient. > > The reason you need both, despite them looking superficially similar, is > that without any XEP-0198 in place you can't actually tell if it was the > message that was lost or the XEP-0184 receipt, and so while the safe thing > to do is warn the user and possibly resend, that may be very irritating for > the recipient. > > The reason you need both, despite them looking superficially similar, is > that without any XEP-0198 in place you can't actually tell if it was the > message that was lost or the XEP-0184 receipt, and so while the safe thing > to do is warn the user and possibly resend, that may be very irritating for > the recipient. > > I hope that makes things clearer, > > Dave. -- Daniele
Re: [Standards] Application-level delivery notification between server and client
I know this thread is going to sleep, but I'd like to stick my oar in. :-) On Tue, Aug 6, 2013 at 9:15 PM, Daniele Ricci wrote: > Please correct me if I'm wrong at any point, just to be sure I > understand XEP 198 and how I can use it in the right way. > > XEP-0198 is designed to make a stream: - Reliable: You know what has definitely been received by the peer. - Recoverable: You can have a stream span TCP connections, in effect, without duplication or loss. But note this *only* has an effect for streams; "chat sessions" span multiple streams - unless you're talking to a server, or using XEP-0174 (Serverless messaging, in case I've got the number wrong) - and so all this is doing is making each leg of the journey reliable. That's important, but not sufficient. > In my case, I can only use the 'h' attribute to store the server-side > message ID. Which I can't do according to the spec. > > Right - h is purely a count. Because it's only one stream, rather than end-to-end, we can do this, and it's sufficient. We could have had and contain random guids or something, but then people would have expected to be able to insert semantic meaning into them, and they don't need that. is the conversational equivalent of saying "Right?" at the end of a sentence, and is the equivalent of saying "Uh-huh" and nodding politely. You don't need to figure out which sentences have been received, because it's just "everything up until this point". But just like a conversation where one side is just grunting and nodding, while you know they've heard, you don't know if there was anything more. > But the biggest and main issue is: a receipt is actually part of a > message. It's not stream management; it means Alice will receive a > delivery receipt when message has been delivered (and acknowledged) by > Bob. I can't just throw off at any time for this purpose - it > would not be stream management any more. That's why I think I need > something half XEP 198 and half XEP 194. > > And you're right - except you don't want half '198 and half '184, you actually want all of both. Whilst XEP-0198 makes streams reliable, to make chat sessions reliable to need XEP-0184, which will then mean you can reliably send a message - and reliably get a receipt back when it's delivered. The reason you need both, despite them looking superficially similar, is that without any XEP-0198 in place you can't actually tell if it was the message that was lost or the XEP-0184 receipt, and so while the safe thing to do is warn the user and possibly resend, that may be very irritating for the recipient. The reason you need both, despite them looking superficially similar, is that without any XEP-0198 in place you can't actually tell if it was the message that was lost or the XEP-0184 receipt, and so while the safe thing to do is warn the user and possibly resend, that may be very irritating for the recipient. The reason you need both, despite them looking superficially similar, is that without any XEP-0198 in place you can't actually tell if it was the message that was lost or the XEP-0184 receipt, and so while the safe thing to do is warn the user and possibly resend, that may be very irritating for the recipient. I hope that makes things clearer, Dave.
