List Info

Thread: XEP-0115 v. 1.5pre14
XEP-0115 v. 1.5pre14
country flaguser name
United States		 2008-01-14 21:33:51 
I have updated the provisional version of XEP-0115 per
recent list 
discussion.

Rendered text:


http://www.xmpp.org/extensions/tmp/xep-0115-1.5.html

SVN diff from 1.5pre13:

http://svn.xmpp.org:18080
/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1572&r2=15
79

SVN diff from 1.4:

http://svn.xmpp.org:18080
/browse/XMPP/trunk/extensions/xep-0115.xml?r1=1145&r2=15
79

Peter

-- 
Peter Saint-Andre
https://stpeter.im/
Re: XEP-0115 v. 1.5pre14
user name
 2008-01-15 01:24:03 
On Jan 15, 2008 3:33 AM, Peter Saint-Andre <stpeterstpeter.im> wrote:
> I have updated the provisional version of XEP-0115 per
recent list
> discussion.

I have only a minor wornesstoing niggle:

The collision and preimage section is a bit unclear - for
the first
halfread I though the terms were reversed (it's not
vulnerable to
collision, but might be to preimage sounds peculiar because
collision
is semi-possible, while preimage isn't), but I think I've
understood
now. Perhaps it could say something like 'not vulnerable to
semi-possible* existing collision techniques, but could be
possible to
pre-image attacks if such are developed in the future."
(*I forget the
term). It might help thickies like me reading the spec.

The 'pre-image would need' section says that it would have
to remove a
feature, but adding a feature could be equally DoS (say you
supported
xhtml-im and so the client stopped sending a <body />
as a poor
example).

I'm much happier with the text now though, thanks Peter.

/K
Re: XEP-0115 v. 1.5pre14
country flaguser name
United States		 2008-01-15 12:14:22 
Kevin Smith wrote:
> On Jan 15, 2008 3:33 AM, Peter Saint-Andre
<stpeterstpeter.im> wrote:
>> I have updated the provisional version of XEP-0115
per recent list
>> discussion.
> 
> I have only a minor wornesstoing niggle:
> 
> The collision and preimage section is a bit unclear -
for the first
> halfread I though the terms were reversed (it's not
vulnerable to
> collision, but might be to preimage sounds peculiar
because collision
> is semi-possible, while preimage isn't), but I think
I've understood
> now. Perhaps it could say something like 'not
vulnerable to
> semi-possible* existing collision techniques, but could
be possible to
> pre-image attacks if such are developed in the
future." (*I forget the
> term). It might help thickies like me reading the
spec.

I've changed the first paragraph of that section to read:

******

As described in RFC 4270 [24], protocols that use the output
of hash 
functions such as MD5 or SHA-1 can be vulnerable to
collision attacks or 
preimage attacks or both. Because of how the hash output is
used in 
entity capabilities, the protocol will not be subject to
collision 
attacks even if the hash function used is found to be
vulnerable to 
collision attacks. However, it is possible that the protocol
might 
become subject to preimage attacks if the hash function used
is found to 
be vulnerable to preimage attacks.

******

> The 'pre-image would need' section says that it would
have to remove a
> feature, but adding a feature could be equally DoS (say
you supported
> xhtml-im and so the client stopped sending a <body
/> as a poor
> example).

I've changed the relevant bullet-point to:

******

The input messsage X or S' would need to make it seem as if
a desirable 
feature (e.g., end-to-end encryption) is not supported by
other entities 
that advertise the same hash V even though the feature is
indeed 
supported (i.e., the attacker would need to return a set of
service 
discovery identities and features that match X or S', and
have that set 
be plausible for an entity that communicates via XMPP), or
make it seem 
as if an undesirable feature is supported even though the
feature is not 
supported.

******

> I'm much happier with the text now though, thanks
Peter.

I'm here for you! 

Peter

-- 
Peter Saint-Andre
https://stpeter.im/
[1-3]

about | contact  Other archives ( Real Estate discussion Medical topics )