On 4/6/11 5:18 AM, Matthew Wild wrote:
> On 6 April 2011 11:11, Kevin Smith <kevin at kismith.co.uk> wrote:
>> On Thu, Mar 24, 2011 at 2:47 PM, Kevin Smith <kevin at kismith.co.uk> wrote:
>>> 3) Accept version 1.8 of XEP-0065?
>>> All to vote on-list within a fortnight.
>>>> I have a quibble that
>> "The JIDs provided MUST be the JIDs used for the IQ exchange between
>> the Requester and the Target, which MAY be full JIDs or bare JIDs ."
>> could be misconstrued as saying that it's fine to choose whether to
>> use the full or bare JIDs (whereas I think that what it's saying is
>> that if the iqs are bare-JID, so should these JIDs be, otherwise
>> full).
>>>> I think s/full or bare// would be fine there.
Kev is right about the intent. Changed in my working copy to:
###
The JIDs used as input to the hash function MUST be the actual JIDs used
for the IQ exchange between the Requester and the Target (these might be
full JIDs (<localpart at domain.tld/resource> or <domain.tld/resource>) or
bare JIDs (<localpart at domain.tld> or <domain.tld>) depending on the
addresses of the entities involved in the negotiation).
###
>> Also, "A Proxy SHOULD monitor usage from particular Requesters and
>> blacklist them if their usage is excessive." mixing normative language
>> with a vague ' do something about it' seems wrong, but this is also
>> non-blocking.
>>>> Proxied streams are bidirectional, it's possible that I open a
> connection to someone else via the proxy and they flood me with data.
> Who do we mark this traffic against? :)
Good point. Changed "Requester" to "entity"...
###
A SOCKS5 Bytestreams Proxy can be subject to denial of service attacks
(e.g., generating a large number of session requests that are never
activated). Proxy deployments are advised to monitor usage from
particular entities and blacklist them if their usage is excessive.
###
> For the other security consideration about hijacking, it only
> questions for me why we don't just use dstaddr all the time (pesky
> backwards compatibility... :) ). I think it is no less secure than
> sending the sid and hashing at each end - anyone who captured the
> stanza then already has all the data they need to produce the hash,
> even if dstaddr isn't included.
Right. It might make sense to move in that direction (if we keep using
S5B instead of moving to ice-tcp as discussed on the jingle@ list recently).
> Anyway, the point is that the security consideration stands today as
> much as it ever did, so it's fine.
>>> I'm ok with publication.
>>>> /K
>>>> +1.
OK.
The diff from 1.8rc4 is here:
http://xmpp.org/extensions/diff/api/xep/0065/diff/1.8rc4/vs/1.8rc5
Rendered:
http://xmpp.org/extensions/tmp/xep-0065-1.8.html
Feedback from anyone else?
Peter
--
Peter Saint-Andre
https://stpeter.im/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/council/attachments/20110412/6979d4dd/attachment-0001.bin>