Re: [Standards] XMPP Security
On 1/29/15 3:25 PM, Cramer, E.R. (Eelco) wrote: This is a great conversation and gives a great insight into standardization politics. ;-) Well, that was in some measure driven by who was on the IESG and general IETF / IESG thinking at that time. Now things might be different. Peter -- Peter Saint-Andre https://andyet.com/
Re: [Standards] XMPP Security
This is a great conversation and gives a great insight into standardization politics. ;-) --- sent from the hand > Op 29 jan. 2015 om 23:07 heeft Peter Saint-Andre - &yet > het volgende geschreven: > >> On 1/29/15 12:13 PM, Philipp Hancke wrote: >> [...] >>> All of them except RFC 3923 are marked as "not recommended to >>> implement", but it's confusing nonetheless. >> >> I think the author of 3923 has never seen or heard of any >> implementations :-) > > We wrote RFC 3923 (and RFC 3922) so that we could get RFC920 and RFC 3921 > published. No one has ever implemented RFC 3923, to the best of my knowledge. > > Peter > > -- > Peter Saint-Andre > https://andyet.com/ This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
Re: [Standards] XMPP Security
On 1/29/15 12:13 PM, Philipp Hancke wrote: [...] All of them except RFC 3923 are marked as "not recommended to implement", but it's confusing nonetheless. I think the author of 3923 has never seen or heard of any implementations :-) We wrote RFC 3923 (and RFC 3922) so that we could get RFC 3920 and RFC 3921 published. No one has ever implemented RFC 3923, to the best of my knowledge. Peter -- Peter Saint-Andre https://andyet.com/
Re: [Standards] XMPP Security
[...] All of them except RFC 3923 are marked as "not recommended to implement", but it's confusing nonetheless. I think the author of 3923 has never seen or heard of any implementations :-)
Re: [Standards] XMPP Security
Hi Michael, > So my question is: What is actually the problem with the latest XMPP > end-to-end encryption and signing approaches and why isn’t it safe against > malicious server operators and sniffing of direct client-to-client > transmissions? And is there anything else I should know? The "XMPP Ubiquitous Encryption Manifesto" is only about Transport Layer encryption as far as I know (between c2s and s2s connections). So a malicious server admin could still read these messages, e.g. while they are stored in an offline store or if they are otherwise logged somewhere in a server archive. Concerning XMPP's end-to-end encryption and signing: It has always confused me, because there are so many specifications out there. I haven't read/understood all of them, but each of them seem to deal with encryption in a different way. http://xmpp.org/rfcs/rfc3923.html http://xmpp.org/extensions/xep-0027.html (obsolete) http://xmpp.org/extensions/xep-0116.html http://xmpp.org/extensions/xep-0187.html http://xmpp.org/extensions/xep-0188.html http://xmpp.org/extensions/xep-0200.html http://xmpp.org/extensions/xep-0210.html http://xmpp.org/extensions/xep-0217.html http://xmpp.org/extensions/xep-0241.html http://xmpp.org/extensions/xep-0274.html http://xmpp.org/extensions/xep-0285.html http://xmpp.org/extensions/xep-0290.html and you even found another one... All of them except RFC 3923 are marked as "not recommended to implement", but it's confusing nonetheless. Maybe the authors of these documents could shed some light on the current state of e2e encryption. - Christian
Re: [Standards] XMPP Security
> So my question is: What is actually the problem with the latest XMPP > end-to-end encryption and signing approaches and why isn’t it safe against > malicious server operators and sniffing of direct client-to-client > transmissions? And is there anything else I should know? Nothing is wrong with latest e2e encryption solution, because there is no accpeted solution :-) There are just many proposals. -- Bartosz Małkowski Tigase Polska xmpp:bmal...@malkowscy.net signature.asc Description: Message signed with OpenPGP using GPGMail
[Standards] XMPP Security
Hello everybody, My name is Michael Fischinger and I am doing some research at the Salzburg University of Applied Science, in particular its about XMPP security. I just read through the latest internet draft about End-to-End Object Encryption and Signatures for the Extensible Messaging and Presence Protocol (XMPP) (http://www.ietf.org/archive/id/draft-miller-xmpp-e2e-07.txt). I am not very experienced with XMPP and its security so far. Thus I have a question according to the following quotation which I have from http://op-co.de/blog/tags/xmpp/: In the light of last year's revelations, it should be clear to everybody that end-to-end encryption is an essential part of any modern IM suite. Unfortunately, XMPP is not there yet. The XMPP Ubiquitous Encryption Manifesto is a step into the right direction, enforcing encryption of client-to-server connections as well as server-to-server connections. However, more needs to be done to protect against malicious server operators and sniffing of direct client-to-client transmissions. So my question is: What is actually the problem with the latest XMPP end-to-end encryption and signing approaches and why isnt it safe against malicious server operators and sniffing of direct client-to-client transmissions? And is there anything else I should know? I would be glad if anyone could help me! I look forward to hearing from you. Yours sincerely, DI Michael Fischinger -- FACHHOCHSCHULE SALZBURG GmbH Salzburg University of Applied Sciences DI Michael Fischinger Wissenschaftlicher Mitarbeiter Informationstechnik & System-Management (ITS) Urstein Süd 1 | 5412 Puch/Salzburg | Austria fon: +43 (0)50 2211 1309 fax: +43 (0)50 2211 1349 web: www.fh-salzburg.ac.at Gerichtsstand Salzburg | FN166054y
