[Standards] (no subject)

2014-10-22 Thread apex 2019 
Hello. I would like to say that i can't use your email because, i don't
undeestand how to use your correct direction to use your email.
Thank you

Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)

2014-10-22 Thread 

On 10/22/14, 9:32 AM, Daurnimator wrote:

On 22 October 2014 09:57, Tobias Markmann mailto:tmarkm...@googlemail.com>> wrote:

I think using a more secure hash function would be beneficial for
reducing code. Secure wireless constrained applications are likely
to already include a high security cryptographic hash function.
Using this hash function would avoid the need of implementing MD5 at
all. Maybe, hash agility could also be useful in this case. So
clients, I think this is the main deployment target for as
constrained device, can pick the one already available. Servers
which are likely to have more power can then simply use the same
hash as the client.


I would think SHA-1 a better choice than MD5 at least.
And clients will already need it for capabilities:
http://xmpp.org/extensions/xep-0115.html#security-mti


See also RFC 6151, which states that MD5 "is no longer acceptable where 
collision resistance is required" (such as in digital signatures).


We can do better than MD5 these days.

Peter

--
Peter Saint-Andre
https://andyet.com/

Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)

2014-10-22 Thread Daurnimator 
On 22 October 2014 09:57, Tobias Markmann  wrote:

> I think using a more secure hash function would be beneficial for reducing
> code. Secure wireless constrained applications are likely to already
> include a high security cryptographic hash function. Using this hash
> function would avoid the need of implementing MD5 at all. Maybe, hash
> agility could also be useful in this case. So clients, I think this is the
> main deployment target for as constrained device, can pick the one already
> available. Servers which are likely to have more power can then simply use
> the same hash as the client.
>

I would think SHA-1 a better choice than MD5 at least.
And clients will already need it for capabilities:
http://xmpp.org/extensions/xep-0115.html#security-mti

Re: [Standards] LAST CALL: XEP-0322 (Efficient XML Interchange (EXI) Format)

2014-10-22 Thread Tobias Markmann 
Hi,

Following inline some feedback. While a little late I hope it’s still useful.

On 08.10.2014, at 18:33, XMPP Extensions Editor  wrote:

> Please consider the following questions during this Last Call and send your 
> feedback to the standards@xmpp.org discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
> clarify an existing protocol?

Yes. It aims to provide higher compression rations compared to general purpose 
compression like ZLib.

> 2. Does the specification solve the problem stated in the introduction and 
> requirements?

I hope so. I haven’t implemented it and the document itself doesn’t show how it 
compares to the currently available general purpose compression methods.
Considering the constrained devices application scenario I would expect the 
compression ratios be as good if not better as general purpose compression and 
that the code required for this is as small in comparison as devices are not 
only constrained in battery energy but also in code storage size and processing 
power..

> 3. Do you plan to implement this specification in your code? If not, why not?

I currently don’t have plans to implement this protocol as my current XMPP 
usage scenarios don’t include extremely constrained devices, where implementing 
EXI would have a benefit justifying the work to implement it.

> 4. Do you have any security concerns related to this specification?

I think using a more secure hash function would be beneficial for reducing 
code. Secure wireless constrained applications are likely to already include a 
high security cryptographic hash function. Using this hash function would avoid 
the need of implementing MD5 at all. Maybe, hash agility could also be useful 
in this case. So clients, I think this is the main deployment target for as 
constrained device, can pick the one already available. Servers which are 
likely to have more power can then simply use the same hash as the client.

> 5. Is the specification accurate and clearly written?

As Philipp already mentioned, the negotiation of the port inside the stream 
features as dedicated compression methods seems quite strange. 
I haven’t read it in all detail but except for some typos it reads okay.

Typo: Once an EXI setup has been accepted by the server, and agreement is 
reched, the… : “reched” -> “reached”

Cheers,
Tobias