Re: [Standards] RFC 3923 (e2e with S/MIME) and OpenPGP
On Tue, Jul 02, 2013 at 09:32:50AM +0200, Daniele Ricci wrote: (1) Matt's work on draft-miller-xmpp-e2e (2) OTR (potentially with future enhancements to make it more XMPP-friendly) Some energy is going into both of those (Paul Wouters and I plan to sync up at the IETF meeting at the end of July to work on an Internet-Draft providing informational documentation about OTR). Since you seem to care about this issue, your feedback would be welcome. Both of these approaches do not protect meta-data (who is talking to whom) and allow for statistical attacks on the packets (guess what's inside by the size etc). More advanced forms of e2e messaging could be torchat and retroshare, although I'm not sure they provide forward secrecy. Since XMPP isn't suitable for keeping meta-data private I would presume that e2e privacy is out of scope for this mailing list, really. No comment on heml.is except that there is a solid lack of competence in its design. You don't do e2e with pgp over servers. That provides neither meta-data privacy nor forward secrecy. Sure! Because my needs are mobile-oriented, I have to implement some e2e solution that works when both users are online or not (something like offline-storage OTR?). Of course an offline solution is less That's the point in OTR: It does a DHE for forward secrecy, but that is only possible when both sides are online. What you can do for offline messages are to choose between these options: - Make the forward secrecy less perfect by keeping a DHE alive until both parties are online at the same time again for renegotiation.. - Use PGP until both are online again, but then warn the user that the message can be decrypted by authorities if his or her device gets seized by police. safe than an online one, but of course there might be a compromise (warning the user that e.g. forward secrecy might be compromised because recipient is offline might be an option). Anyway, please keep this in mind when you will discuss your new Internet-Draft. Yes, and you should also warn the user that if her smartphone still has the factory operating system there may already be an NSA backdoor in place before even installing any communications software. IMHO the only way to offer a confidential e2e communications experience over smartphones is by offering an operating system replacement with builtin onion routing messaging layer.. be it tor, retroshare or gnunet. XMPP is no longer appropriate for this scenario.
Re: [Standards] RFC 3923 (e2e with S/MIME) and OpenPGP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/16/13 4:27 AM, Carlo v. Loesch wrote: On Tue, Jul 02, 2013 at 09:32:50AM +0200, Daniele Ricci wrote: (1) Matt's work on draft-miller-xmpp-e2e (2) OTR (potentially with future enhancements to make it more XMPP-friendly) Some energy is going into both of those (Paul Wouters and I plan to sync up at the IETF meeting at the end of July to work on an Internet-Draft providing informational documentation about OTR). Since you seem to care about this issue, your feedback would be welcome. Both of these approaches do not protect meta-data (who is talking to whom) and allow for statistical attacks on the packets (guess what's inside by the size etc). Neither OTR nor Matt's approach claim to protect metadata. More advanced forms of e2e messaging could be torchat and retroshare, although I'm not sure they provide forward secrecy. I'm sure other approaches will be emerging soon, given recent events. Since XMPP isn't suitable for keeping meta-data private I would presume that e2e privacy is out of scope for this mailing list, really. True. No comment on heml.is except that there is a solid lack of competence in its design. You don't do e2e with pgp over servers. That provides neither meta-data privacy nor forward secrecy. Sure! Because my needs are mobile-oriented, I have to implement some e2e solution that works when both users are online or not (something like offline-storage OTR?). Of course an offline solution is less That's the point in OTR: It does a DHE for forward secrecy, but that is only possible when both sides are online. What you can do for offline messages are to choose between these options: - Make the forward secrecy less perfect by keeping a DHE alive until both parties are online at the same time again for renegotiation.. - Use PGP until both are online again, but then warn the user that the message can be decrypted by authorities if his or her device gets seized by police. safe than an online one, but of course there might be a compromise (warning the user that e.g. forward secrecy might be compromised because recipient is offline might be an option). Anyway, please keep this in mind when you will discuss your new Internet-Draft. Yes, and you should also warn the user that if her smartphone still has the factory operating system there may already be an NSA backdoor in place before even installing any communications software. IMHO the only way to offer a confidential e2e communications experience over smartphones is by offering an operating system replacement with builtin onion routing messaging layer.. be it tor, retroshare or gnunet. XMPP is no longer appropriate for this scenario. Life was different back in 1999 and we were all more innocent. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR5YMlAAoJEOoGpJErxa2pdfUQAJyT7bwMeqUvcEb1suN4W7UN ATOJscwFVBGuup+DAp7CHSOC/ynLHh/MoSfwUYvHhUKC4SKmGMr/7Ikq6XBsXtpT nX7NEDFXw2fDJKi48ItO8zVZkIzCghhYZ1PUkOK0FMyz8Im1YrzHXIH1oq2spJrt OIDSoM1DJFv26QwSrp3+w0er3LC1Gj22d+jM2Vxfr8GOgC4vKwXGdWg7hz1VkRLg CJ7t93gStIlG9wcFJ2fCnTiLg/bWoGK0uXLNHdHnoa5CMvccsXrfwKNG0T2/4m7G tcq5JRa+Q+OU4W0rl38yBx2fIb8lzG9pPiQAfeweem6W0zIVJgKk2raFrKtOL46v a5cLIm09dPQVGrxFkpx4wdzxLaysRx9lQs0v3XMmgw7MugBVzOeNfTSDoNoUvCY/ 5tdDxYOzHSiqujVJYsq61R8hU1z737ounPoqslRromIDPpvp8BQu3WMIKz5dAnaF ruH5gBawbZGG2/VVURoSq+IBUdprV3vYtW07C8UQEBP68YBl7ipJbBucyKnzhzQH 7KK9q1zFo0fSgDH9WBuSVCdaD8S2LwjTi587KIf1RRleWTMefb/kMrUHy0AnAx9+ Gq2GrTZlJ3PSZmS+mqnXPhQYQrRTq164oichUznpBJlOZyVWetdqjqrP2WStck6s pjt0NDE4GF+MfTo9GiRS =4aEI -END PGP SIGNATURE-
Re: [Standards] RFC 3923 (e2e with S/MIME) and OpenPGP
On Mon, Jul 1, 2013 at 7:06 PM, Peter Saint-Andre stpe...@stpeter.im wrote: What about applying PGP/MIME instead As in http://xmpp.org/extensions/xep-0027.html perhaps? I mean using PGP/MIME the same way RFC 3923 uses S/MIME. I think you mean: draft-miller-xmpp-e2e replaces RFC 3923. Yes, I put the * symbol because there were several draft versions of that spec :-) Is there some draft to follow/improve where e2e+PGP/MIME is defined? XEP-0027. You mean in the meantime that a more safe spec is drafted? (1) Matt's work on draft-miller-xmpp-e2e (2) OTR (potentially with future enhancements to make it more XMPP-friendly) Some energy is going into both of those (Paul Wouters and I plan to sync up at the IETF meeting at the end of July to work on an Internet-Draft providing informational documentation about OTR). Since you seem to care about this issue, your feedback would be welcome. Sure! Because my needs are mobile-oriented, I have to implement some e2e solution that works when both users are online or not (something like offline-storage OTR?). Of course an offline solution is less safe than an online one, but of course there might be a compromise (warning the user that e.g. forward secrecy might be compromised because recipient is offline might be an option). Anyway, please keep this in mind when you will discuss your new Internet-Draft. -- Daniele
[Standards] RFC 3923 (e2e with S/MIME) and OpenPGP
Greetings, I was reading RFC 3923 [1], and it always talks about S/MIME encrypted message format. What about applying PGP/MIME instead - or better, let the RFC handle both cases? If I understand correctly, draft-miller-xmpp-e2e-* are replaced by RFC 3923. Is there some draft to follow/improve where e2e+PGP/MIME is defined? By the way: encryption/signing in XMPP is very confusing: there are at least a dozen documents (RFCs and XEPs) defining it - of course I should follow approved XEPs and RFCs, but I'm also looking around: maybe some XEPs are already widely implemented or they will be approved soon. Thank you, Cheers [1] http://tools.ietf.org/html/rfc3923 -- Daniele
Re: [Standards] RFC 3923 (e2e with S/MIME) and OpenPGP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/1/13 10:24 AM, Daniele Ricci wrote: Greetings, I was reading RFC 3923 [1], Yeah, we're not proud of that spec. and it always talks about S/MIME encrypted message format. IETF dogma at the time required that. What about applying PGP/MIME instead As in http://xmpp.org/extensions/xep-0027.html perhaps? - or better, let the RFC handle both cases? That can introduce more complexity. If I understand correctly, draft-miller-xmpp-e2e-* are replaced by RFC 3923. I think you mean: draft-miller-xmpp-e2e replaces RFC 3923. Is there some draft to follow/improve where e2e+PGP/MIME is defined? XEP-0027. By the way: encryption/signing in XMPP is very confusing: there are at least a dozen documents (RFCs and XEPs) defining it - of course I should follow approved XEPs and RFCs, but I'm also looking around: maybe some XEPs are already widely implemented or they will be approved soon. I admire your optimism. :-) The technologies that seem most interesting now are: (1) Matt's work on draft-miller-xmpp-e2e (2) OTR (potentially with future enhancements to make it more XMPP-friendly) Some energy is going into both of those (Paul Wouters and I plan to sync up at the IETF meeting at the end of July to work on an Internet-Draft providing informational documentation about OTR). Since you seem to care about this issue, your feedback would be welcome. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR0bb/AAoJEOoGpJErxa2pQQwP/2yKChW9gl/C0a1zEr3rgWgP uvion1cHU6GEorA+i7xu1x0yPNLaaEKYMxGYoOzgFFR4MRfU+/C8fv1OtqMq1P9P LONY517AZQzR3VFqbi924q5Sf6WA/KHrTXDMQ248xx5u55oo7zoJH6keFt6mEK8w GusU4FerDRqnQ5s3G1eHTwWAqFR011NJmBD9xYSOzylZpbdNqZMjUcXIu61iU2w1 FM/i56L45MhufRVj2ALQB4H9i6J6MC2Xd74/jkM2InAMJT7d8GOFeueO3FQoNhn9 X+UGHwi8u9QrsxDntP43PQ1Yv5OEMvLnaVznNioFOIp1R8F1HJpch1qI9XNXJO+I P7mjdw1ZR8NgfAjD8Z6CZYKT6bE4Ty4hkJSvvJcoRuDWEhBaMyzrCnfqAC0jAnZe JoIEhInI9QSrD/5UrFdXRDGFTMkHBfl38C+tL3Zj1AdSenOhcM7qcNDXTtqbmQ9Q 9HsPe+lUnrCXgM94Bq0wVc88IYQAyGICpFFa/qSJbDUGFR56uyAE3HQFSnmZ972d 0g79uAV75OssqFSNonxRMunXOETqzkNZrDXcA0PXRJ3q6D15o2NJflfqPDkdzNWA X4vfBdUQoRn8EkZesQi+4wNz35MyklNUYuRDcYdbrZLPRGLtLpBFMYv7BowgdrPl tXp4uj5AwB6BL+v76OQZ =tnDu -END PGP SIGNATURE-
