[Council] Minutes 2011-03-23

Peter Saint-Andre stpeter at stpeter.im
Tue Apr 12 17:26:50 UTC 2011

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.


The diff from 1.8rc4 is here:




Feedback from anyone else?


Peter Saint-Andre

-------------- 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>

More information about the Council mailing list