On Fri Sep 16 21:15:43 2011, Florian Zeitz wrote:
Hence a new protocol dropping the old one at the same will:
a) Make old implementations send IQ queries to the new
implementations.
Number of IQs increases with the number of implementers of the new
protocol for some time, but at a certain poin
I think I need some clarification here. I don't see why so many insist
on fixing the current caps protocol.
Caps is an optimization over regular disco. Ideally even dropping it
altogether would not leave anything broken. There are by now XEPs which
require caps, but most (all?) of them only requir
On 9/14/11 4:31 PM, "Waqas Hussain" wrote:
> An entity which understood double verify would have the option to
> either be vulnerable to poisoning, or participate in IQ floods. It's
> this that I'm against.
Presumably, the new XEP would recommend that you negatively cache in the
case that it re
On Sep 14, 2011, at 16:31, Waqas Hussain wrote:
> On Thu, Sep 15, 2011 at 1:37 AM, Matthew A. Miller
> wrote:
>>
>> On Sep 14, 2011, at 13:40, Waqas Hussain wrote:
>>
>>>
>>> So.. which caps is included in presence? The current exploitable one?
>>> Then this doesn't help with preventing poison
On Thu, Sep 15, 2011 at 1:37 AM, Matthew A. Miller
wrote:
>
> On Sep 14, 2011, at 13:40, Waqas Hussain wrote:
>
>>
>> So.. which caps is included in presence? The current exploitable one?
>> Then this doesn't help with preventing poisoning, does it?
>>
>
> the caps hash would be as it is today. S
On Sep 14, 2011, at 13:40, Waqas Hussain wrote:
> On Wed, Sep 14, 2011 at 12:04 AM, Matthew A. Miller
> wrote:
>>
>> On Sep 13, 2011, at 12:18, Matthew A. Miller wrote:
>>
>>
>>> I've been thinking of something that might be a less-awful compromise.
>>> I'll post to this list about it soon
On Wed, Sep 14, 2011 at 12:04 AM, Matthew A. Miller
wrote:
>
> On Sep 13, 2011, at 12:18, Matthew A. Miller wrote:
>
>
>> I've been thinking of something that might be a less-awful compromise. I'll
>> post to this list about it soon for us all to mock and ridicule (-:
>>
>
> So, the less-awful c
On Tue, Sep 13, 2011 at 2:22 AM, Peter Saint-Andre wrote:
> On 9/7/11 8:51 PM, Peter Saint-Andre wrote:
>> On 9/7/11 2:33 PM, Joe Hildebrand wrote:
>>> On 9/5/11 6:39 AM, "Dave Cridland" wrote:
>>>
Of course, it may be simplest just to bite the bullet and switch hash
algorithm - or even
On 9/13/11 3:57 AM, "Dave Cridland" wrote:
> - The FORM_TYPE is used to distinguish between sets of metadata; I
> think forcing all FORM_TYPEs used to be the same would effectively
> mean that only one XEP-0128 extension could be used,
Yes, that was the intent.
> and whilst I cannot think of a
On Sep 13, 2011, at 12:18, Matthew A. Miller wrote:
> I've been thinking of something that might be a less-awful compromise. I'll
> post to this list about it soon for us all to mock and ridicule (-:
>
So, the less-awful compromise I was talking about is this:
We develop a XEP-0128 extensio
On Sep 13, 2011, at 03:57, Dave Cridland wrote:
> On Mon Sep 12 22:22:01 2011, Peter Saint-Andre wrote:
>> One way to solve this problem is to define a new algorithm, either in a
>> revision to XEP-0115 or in a new spec with a new namespace. To conserve
>> space in presence, we'd prefer to avoid
On Mon Sep 12 22:22:01 2011, Peter Saint-Andre wrote:
One way to solve this problem is to define a new algorithm, either
in a
revision to XEP-0115 or in a new spec with a new namespace. To
conserve
space in presence, we'd prefer to avoid a new namespace. So that it
is
possible to continue us
On Montag, 12. September 2011 at 23:22, Peter Saint-Andre wrote:
> One of the major problems with the current approach is that there's no
> hard border between identities and features, and between features and
> extensions. As a result, malicious software can define certain clever
> identities and
On 9/7/11 8:51 PM, Peter Saint-Andre wrote:
> On 9/7/11 2:33 PM, Joe Hildebrand wrote:
>> On 9/5/11 6:39 AM, "Dave Cridland" wrote:
>>
>>> Of course, it may be simplest just to bite the bullet and switch hash
>>> algorithm - or even change the 'hash' attribute name - because then
>>> it'll get tre
On 9/7/11 2:33 PM, Joe Hildebrand wrote:
> On 9/5/11 6:39 AM, "Dave Cridland" wrote:
>
>> Of course, it may be simplest just to bite the bullet and switch hash
>> algorithm - or even change the 'hash' attribute name - because then
>> it'll get treated as a pre-1.4 caps by the vast majority of ent
On 9/5/11 1:54 PM, "Dave Cridland" wrote:
>>> Let's say that we add (yet) another attribute to the caps element,
>>> indicating that the "new" restrictions are in place. (These might include
>>> the various restrictions mentioned in this thread).
>>>
>>> Now, when a client sees a caps marked as
On 9/5/11 6:39 AM, "Dave Cridland" wrote:
> Of course, it may be simplest just to bite the bullet and switch hash
> algorithm - or even change the 'hash' attribute name - because then
> it'll get treated as a pre-1.4 caps by the vast majority of entities
> and everything will happen right (or at
On Mon Sep 5 18:51:16 2011, Waqas Hussain wrote:
On Mon, Sep 5, 2011 at 5:39 PM, Dave Cridland
wrote:
> On Wed Aug 31 06:48:26 2011, Waqas Hussain wrote:
>>
>> Most protocol attacks are based on unexpected input. Attackers
>> wouldn't really care whether the values they send are registered
On Mon, Sep 5, 2011 at 5:39 PM, Dave Cridland wrote:
> On Wed Aug 31 06:48:26 2011, Waqas Hussain wrote:
>>
>> Most protocol attacks are based on unexpected input. Attackers
>> wouldn't really care whether the values they send are registered or
>> usable in any way, as long as the attack succeeds.
On Wed Aug 31 06:48:26 2011, Waqas Hussain wrote:
Most protocol attacks are based on unexpected input. Attackers
wouldn't really care whether the values they send are registered or
usable in any way, as long as the attack succeeds. I don't think you
are proposing all caps handling entities ship w
Am 31.08.2011 07:48, schrieb Waqas Hussain:
> On Wed, Aug 31, 2011 at 7:10 AM, Peter Saint-Andre wrote:
>>
>> So, to use examples closer to real life...
>>
>>
>> EXAMPLE 1
>>
>>
>>
>> is the same as:
>>
>>
>>
>>
>> EXAMPLE 2
>>
>>
>>
>> is the same as:
>>
>>
>>
>> note: "http://jabber.org"; an
On Wed, Aug 31, 2011 at 7:10 AM, Peter Saint-Andre wrote:
> On 8/30/11 5:41 PM, Waqas Hussain wrote:
>>> Can we agree that attacks #1, #3, and #4 are easily overcome by proper
>>> handling of inputs?
>>>
>>
>> Those examples, yes. The attack, no. Read my response to your other
>> email for a descr
On 8/30/11 5:41 PM, Waqas Hussain wrote:
> On Wed, Aug 31, 2011 at 1:41 AM, Peter Saint-Andre wrote:
>> Replying to myself before I reply to the latest message from Waqas. :)
>>
>> On 8/30/11 12:37 PM, Peter Saint-Andre wrote:
>>
>>> So far, two of the attacks (#3 and #4) that you have described (
On Wed, Aug 31, 2011 at 1:41 AM, Peter Saint-Andre wrote:
> Replying to myself before I reply to the latest message from Waqas. :)
>
> On 8/30/11 12:37 PM, Peter Saint-Andre wrote:
>
>> So far, two of the attacks (#3 and #4) that you have described (via
>> examples only) depend on violations of th
On 8/30/11 2:08 PM, Waqas Hussain wrote:
> On Tue, Aug 30, 2011 at 11:37 PM, Peter Saint-Andre
> wrote:
>> On 8/30/11 10:58 AM, Waqas Hussain wrote:
>>>
>>> The problem here seems to be people focusing on the exact bytes of the
>>> example I happened to type out for these attacks, and not the gen
Replying to myself before I reply to the latest message from Waqas. :)
On 8/30/11 12:37 PM, Peter Saint-Andre wrote:
> So far, two of the attacks (#3 and #4) that you have described (via
> examples only) depend on violations of the XML spec and XEP-0030.
>
> Another of the attacks (#1) depends o
On Tue, Aug 30, 2011 at 11:37 PM, Peter Saint-Andre wrote:
> On 8/30/11 10:58 AM, Waqas Hussain wrote:
>>
>> The problem here seems to be people focusing on the exact bytes of the
>> example I happened to type out for these attacks, and not the general
>> logic of the attacks themselves.
>
> Perha
On 8/30/11 10:58 AM, Waqas Hussain wrote:
> On Tue, Aug 30, 2011 at 5:49 AM, Peter Saint-Andre wrote:
>> On 8/26/11 4:32 PM, Waqas Hussain wrote:
>>>
>>> The proposed changes don't solve the problem. See what I wrote in the
>>> "Attempting to fix the algorithm" section of the email you linked.
>>>
On Tue, Aug 30, 2011 at 5:49 AM, Peter Saint-Andre wrote:
> On 8/26/11 4:32 PM, Waqas Hussain wrote:
>>
>> The proposed changes don't solve the problem. See what I wrote in the
>> "Attempting to fix the algorithm" section of the email you linked.
>> Particularly "As far as I can see, there is no w
On 8/29/11 7:30 PM, Matthew A. Miller wrote:
>
> On Aug 29, 2011, at 18:40, Peter Saint-Andre wrote:
>
>> On 8/29/11 9:18 AM, Matthew A. Miller wrote:
>>>
>>> On Aug 27, 2011, at 01:41, Pedro Melo wrote:
>>>
Hi,
On Sat, Aug 27, 2011 at 12:52 AM, Matthew A. Miller
wrote:
>
On Aug 29, 2011, at 18:40, Peter Saint-Andre wrote:
> On 8/29/11 9:18 AM, Matthew A. Miller wrote:
>>
>> On Aug 27, 2011, at 01:41, Pedro Melo wrote:
>>
>>> Hi,
>>>
>>> On Sat, Aug 27, 2011 at 12:52 AM, Matthew A. Miller
>>> wrote:
On Aug 26, 2011, at 16:32, Waqas Hussain wrote:
> O
On 8/29/11 9:18 AM, Matthew A. Miller wrote:
>
> On Aug 27, 2011, at 01:41, Pedro Melo wrote:
>
>> Hi,
>>
>> On Sat, Aug 27, 2011 at 12:52 AM, Matthew A. Miller
>> wrote:
>>> On Aug 26, 2011, at 16:32, Waqas Hussain wrote:
On Sat, Aug 27, 2011 at 1:53 AM, Samantha Mizzi
wrote: The p
On Aug 27, 2011, at 01:41, Pedro Melo wrote:
> Hi,
>
> On Sat, Aug 27, 2011 at 12:52 AM, Matthew A. Miller
> wrote:
>> On Aug 26, 2011, at 16:32, Waqas Hussain wrote:
>>> On Sat, Aug 27, 2011 at 1:53 AM, Samantha Mizzi wrote:
>>> The proposed changes don't solve the problem. See what I wrote i
Hi,
On Sat, Aug 27, 2011 at 12:52 AM, Matthew A. Miller
wrote:
> On Aug 26, 2011, at 16:32, Waqas Hussain wrote:
>> On Sat, Aug 27, 2011 at 1:53 AM, Samantha Mizzi wrote:
>> The proposed changes don't solve the problem. See what I wrote in the
>> "Attempting to fix the algorithm" section of the
Hi,
On Sat, Aug 27, 2011 at 4:14 PM, Ralph Meijer wrote:
> On Sat Aug 27 2011 07:24:14 AM CEST, Jehan Pagès
> wrote:
>
>
>> Too bad the namespace does not follow the URN format, where we could
>> simply update the version to change the hash definition.
>
> 'Simply updating the version' creates
On Sat Aug 27 2011 07:24:14 AM CEST, Jehan Pagès
wrote:
> Too bad the namespace does not follow the URN format, where we could
> simply update the version to change the hash definition.
'Simply updating the version' creates an entirely new namespace. There is no
magic here. Namespace URIs are
Hi,
On Sat, Aug 27, 2011 at 9:07 AM, Waqas Hussain wrote:
> On Sat, Aug 27, 2011 at 4:52 AM, Matthew A. Miller
>>> I'm still in favor of a clean new algorithm and XEP, which can also fix
>>> many of the non-algorithmic issues with the XEP.
>>
>> I personally would like to explore the possibilitie
37 matches
Mail list logo
