Re: [Standards] OTR
> Wiadomość napisana przez Daniele Ricci w dniu 3 > lut 2015, o godz. 12:20: > > The only problem here is how to recognise the encrypted data? Is it a > text body or a stanza? Maybe we can use a "type" attribute to , > revealing more metadata? Or maybe we could add a header to the > encrypted data: I don’t understand. If client receives … then it will decrypt data and expect that result of decryption is stanza (or maybe other element allowed in XMPP Stream), then client will process received and decrypted element like any other received elements. Look at https://tools.ietf.org/html/draft-miller-xmpp-e2e-02 (4.3. Example - Securing a Message). The same idea. -- Bartosz Małkowski Tigase Polska xmpp:bmal...@malkowscy.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] OTR
> Wiadomość napisana przez Peter Saint-Andre - &yet w dniu 2 > lut 2015, o godz. 19:47: > > OTR secures only the character data of the XMPP element within > message stanzas. That's appropriate for IM but doesn't really help with > things like IoT (which often use extended namespaces). Thats why we are trying (again!) to prepare e2e encryption specification (one more!). ;-) What you decided during Summit? I hope you have talks about e2e encryption. I just changed architecture of my XMPP library to allow set up „virtual XMPP Streams” between two entities, but I can’t use it :-( -- Bartosz Małkowski Tigase Polska xmpp:bmal...@malkowscy.net signature.asc Description: Message signed with OpenPGP using GPGMail
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
Re: [Standards] OTR
> Wiadomość napisana przez Steffen Larsen w dniu 26 sty > 2015, o godz. 09:19: > > A good discussion for the summit I would say. :-) > :-) Indeed. Let decide something. I’m changing architecture of my XMPP library to allow easy extend it by any implementation of virtual xmpp streams :-) I will be able to add implementation of all e2e encryption protocols ;-) Regards! -- Bartosz Małkowski Tigase Polska xmpp:bmal...@malkowscy.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] OTR
https://blog.thijsalkema.de/me/blog//blog/2015/01/23/multi-end-to-multi-end-encryption/ -- Bartosz Małkowski Tigase Polska xmpp:bmal...@malkowscy.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] OTR
> Wiadomość napisana przez Sam Whited w dniu 29 gru 2014, > o godz. 18:36: > > The main problem I see there would be deniability; a lot of things I see > people suggest would potentially ruin the ability of the protocol to > provide deniability. Can you explain? If encrypted stream will be established, then what problems you see? We can’t hide fact that OTR stream is established between two entities. -- Bartosz Małkowski Tigase Polska xmpp:bmal...@malkowscy.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] OTR
Hi! I’m thinking if we should add something (optional) to prove that OTR Key is trusted. I think about something based on for example OpenPGP signatures: E9017BCCF047B363A8ED281F2DE31972BECB3F34 hQEMA/cDyEqkT1m7AQf/ejLVE4KnNKJ8yPjMAn9C6OdCrwkZZ50YcrHjRIMkmGYB … QFElQwI1RKtS/SBY+CneY0eAIrLFNuW7Y7R/Qpt4jP2+UBpzCyzRzf/PVXfkK9iJ zmqXfw== =Aj0L Where signature is for example OpenPGP_Sign(otr_key_hash). I don’t know if it should be stored somewhere (like VCard) or should be generated on request. I event don’t know if it is necessary or not ;-) -- Bartosz Małkowski Tigase Polska xmpp:bmal...@malkowscy.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] OTR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ok. I think we should determine goals we want to achieve and more or less features of this protocol. As short list. - -- Wysłane za pomocą K-9 Mail. -BEGIN PGP SIGNATURE- Version: OpenKeychain v3.2beta1 iQFQBAEBCAA6MxxCYXJ0b3N6IE1hbGtvd3NraSAoYm1hbGtvdykgPGJtYWxrb3dz a2lAdGlnYXNlLnBsPgUCVJmSOAAKCRCoAdab0OzG42V8CADjlmUqyvHLj+l8GxGb 38jUueTkldCY1rOuMILhAtCmFpn5pQkGAzGLKLvQUoxf3FGmjGpD6d6XDQO/UZtk XYdiUj7SKlpM+kUUP8fewHHMeGsymyS+eA0q6AVSiC2y010MQuJWl9z+JxSziiYg G4yEbdL3xXBEk7iQbGiMMQ81TF4inB92uN51Xe9SbKF7wuievkjuyu26mDb+AJ4w R6iwGU3Mgf1jSJZMM3cn0oGJ6om2db4+6s81VOZ0kT/N5fMzX1/EUYuuCX4gD8l4 muXx2p2WwblHHbaZOtFguq7IRGRs8xsGvmdrHnr/NVzkZPsE96GDMuVZoHFIPRp+ 8YRa =vGOI -END PGP SIGNATURE-
Re: [Standards] OTR
> Wiadomość napisana przez Florian Schmaus w dniu 23 gru > 2014, o godz. 11:14: > > I see two design issues. You already mentioned the custom type value. > Never invent new values for defined (top level) elements or new > attributes (XEP-0134 § 2.1). > > Also your custom (OTR) payload should (must?) be encapsulated into a > extension element. So your example becomes: > > > > > > Don’t shoot! I assume that it was just example to illustrate solution. :-) -- Bartosz Małkowski Tigase Polska xmpp:bmal...@malkowscy.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] OTR
> Wiadomość napisana przez Sam Whited w dniu 22 gru 2014, > o godz. 19:16: > > We couldn't hide the fact that communication happens between A and B, > but we could hide what type of communication happens. Eg. are messages > being exchanged, is presence being exchanged, are files being exchanged, > etc. > Right! When I was thinking more about it, I have to agree with you. This is best solution for full e2e encytpion. -- Bartosz Małkowski Tigase Polska xmpp:bmal...@malkowscy.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] OTR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm not sure we should start new XMPP stream covered by OTR. It depends on what we want to do. We can't hide that communication between A and B happens. Does encrypting whole stanzas is worth of complications? Dnia 17 grudnia 2014 17:46:18 CET, Winfried Tilanus napisał(a): >On 05-12-14 11:24, Goffi wrote: > >Hi, > >> Is there any update on this ? Actually the situation is not really >good today: >> some client encode XML in OTR, other don't, there is no way to >advertise OTR >> support with discovery and there is an OTR specific advertisement way >(with >> whitespace-tagged messages). OTR need to work with non XMPP gateways. >It would >> be really good to standardize all that... > >I had some discussion with Ian Goldberg (one of the OTR-guys) on this. >Their initial choice was to do OTR in plain messages (with their >somewhat strange way of discovering support and starting sessions), so >it would be easy to use OTR in a multi-protocol environment. In >response >to my comment that it left a lot of information unencrypted he >suggested >to start a second OTR protocol in XMPP, one that does proper service >discovery and properly encrypts everything of the stanzas that should >be >encrypted. Optionally embedding the plain version within it when you >need to transverse to an other protocol. > >Well... I think the first step should be documenting the most common >case, OTR'ing the content of a message in the OTR way > >Winfried - -- Wysłane za pomocą K-9 Mail. -BEGIN PGP SIGNATURE- Version: OpenKeychain v3.2beta1 iQFQBAEBCAA6MxxCYXJ0b3N6IE1hbGtvd3NraSAoYm1hbGtvdykgPGJtYWxrb3dz a2lAdGlnYXNlLnBsPgUCVJhGpQAKCRCoAdab0OzG44/JB/0ZNJCOTYlLaNqENOox ybj8Qosn7QD+El/W0UE7yrHByAg5BwrjzyRpCitvWE7CT8AfHPtJHx9IBTj2zdSW U2BXKeO4rFrCwt1UEm2EquPZYyAduYuqQ7yx4sl4C77qF5uz7H/yYck3b0i+v6Yu 5JZVGB5p/fVFSyYOZLOqRGrYVeWIZoiKINTtAlOlFqcUmP2m9iKVm/ovrdIDB43i UYQ+f1LdTp+mG42WYrEmdOvnKzsiDqARic/wxNO+E6YGiGVKat2ETZqT1WN1hQ1O bTj/SoeKh3pjq8opMpDZFXE27QKHvP6Qhu5WKVk7UL8AYak1eh9I8hEzpHedsxDS zt5C =tO/+ -END PGP SIGNATURE-
Re: [Standards] OTR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm in too. I haven't experience with writing xep, but I'm interested in securing communication. - -- Wysłane za pomocą K-9 Mail. -BEGIN PGP SIGNATURE- Version: OpenKeychain v3.1.2 iQFQBAEBCAA6MxxCYXJ0b3N6IE1hbGtvd3NraSAoYm1hbGtvdykgPGJtYWxrb3dz a2lAdGlnYXNlLnBsPgUCVF02kQAKCRCoAdab0OzG416DB/9aeRmZyaS5YvwAyj3T byJiSQfmMKvc3E6W69R2Udt7HWU0dGEKZT3yt9gA7cwZs6plkPncp5ZzmAxOHPL4 IdC708GA+TgnLFgxy/NjprwKHmHEZZxxADvcS6JUbx1xdnRrmyR+cUIYRDh+WidW f/eyFkO4np8HqkY/X2HD1YVLRTKMxlf5pat7HVTDGmSBOWhNQbrNSYjKo+1A7Uy7 8O4tYwYkH77Lj5SsLFlsSnChKIaiYuKYm+bmar3GouKNe45CUhcy2x8t4KvJ7liE 1qQP74RjlP9bmnGsyZPdjAcFgihok0+drWS3NzRrPiFUhPgX+EcwFBBJzG05lMMj IIoT =0WcU -END PGP SIGNATURE-
Re: [Standards] OTR
> Wiadomość napisana przez Ashley Ward w dniu 7 lis > 2014, o godz. 16:32: > > > Just as long as Romeo and Juliet don’t commit suicide too. Wait, what’s that > you say…? In worst case we still have Kermit the Frog, Animal, GOnzo and Dr. Teeth (https://wiki.asterisk.org/wiki/display/AST/AMI+v2+Specification). -- Bartosz Małkowski Tigase Polska xmpp:bmal...@malkowscy.net smime.p7s Description: S/MIME cryptographic signature
