From stpeter at stpeter.im Mon Mar 2 16:03:34 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Mon, 02 Mar 2009 15:03:34 -0700 Subject: [Security] XTLS and DTLS-SRTP Message-ID: <49AC57B6.8050109@stpeter.im> [sent to security at xmpp.org with cc's for non-list-members] The "XTLS" specification that Dirk Meyer and I have been working on enables two entities to establish TLS over a Jingle transport method before exchanging application data over the transport: http://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-00 The primary use case we've had in mind is secure end-to-end XML streams over a streaming transport such as in-band bytestreams (mainly for the purpose of encrypted text chat). However, this protocol could also be used to secure a datagram transport such as UDP via DTLS (instead of a streaming transport via TLS). In fact the signalling is quite similar to DTLS-SRTP: http://tools.ietf.org/html/draft-ietf-sip-dtls-srtp-framework http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp In particular, the XTLS element would map to the SDP a=fingerprint line, as shown in the following pseudo-examples (I have not checked all the specifics so there might not be a complete mapping between the XMPP and the SIP+SDP). action='session-initiate' initiator='romeo at montague.lit/orchard' sid='a73sjjvkla37jfea'> RomeoX509CertificateHash INVITE sip:juliet at capulet.lit SIP/2.0 To: From: ;tag=843c7b0b Via: SIP/2.0/TLS ua1.montague.lit;branch=z9hG4bK-0e53sadfkasldkfj Contact: Call-ID: 6076913b1c39c212 at REVMTEpG CSeq: 1 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE Max-Forwards: 70 Content-Type: application/sdp Content-Length: xxxx Supported: from-change v=0 o=- 1181923068 1181923196 IN IP4 ua1.montague.lit s=example1 c=IN IP4 ua1.montague.lit a=setup:actpass a=fingerprint: SHA-1 RomeoX509CertificateHash t=0 0 m=audio 6056 RTP/AVP 0 a=sendrecv a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP a=pcfg:1 t=1 I see a few differences here that we might want to harmonize: 1. The a=fingerprint line specifies the hashing algorithm used, whereas the XTLS element does not. We could easily add an 'algo' attribute to the element. 2. The XTLS element enables a party to provide a hint about which TLS methods might be used (e.g., "x509" or "srp"), whereas no SDP methods are defined for that functionality. I could work with the authors of DTLS-SRTP to include something along these lines. Feedback is welcome. I will look into incorporating some of this thinking into the Jingle RTP Sessions specification: http://xmpp.org/extensions/xep-0167.html Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090302/57daefd0/attachment.bin From dmeyer at tzi.de Mon Mar 2 16:33:36 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Mon, 02 Mar 2009 23:33:36 +0100 Subject: [Security] XTLS and DTLS-SRTP In-Reply-To: <49AC57B6.8050109@stpeter.im> (Peter Saint-Andre's message of "Mon\, 02 Mar 2009 15\:03\:34 -0700") References: <49AC57B6.8050109@stpeter.im> Message-ID: <87ab83wo5b.fsf@phex.sachmittel.de> Peter Saint-Andre wrote: > 1. The a=fingerprint line specifies the hashing algorithm used, whereas > the XTLS element does not. We could easily add an 'algo' > attribute to the element. I also got feedback that we missed that. We should add it in -01 > 2. The XTLS element enables a party to provide a hint about > which TLS methods might be used (e.g., "x509" or "srp"), whereas no SDP > methods are defined for that functionality. I could work with the > authors of DTLS-SRTP to include something along these lines. How do they solve the problem of bootstrapping trust? We could force x509 if we talk to SIP clients, e.g. a SIP client will always support this methid and has no fallback. I know, that sucks. Dirk -- Hanson's Treatment of Time: There are never enough hours in a day, but always too many days before Saturday. From ekr at rtfm.com Mon Mar 2 16:35:31 2009 From: ekr at rtfm.com (Eric Rescorla) Date: Mon, 2 Mar 2009 14:35:31 -0800 Subject: [Security] XTLS and DTLS-SRTP In-Reply-To: <87ab83wo5b.fsf@phex.sachmittel.de> References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> Message-ID: >> 2. The XTLS element enables a party to provide a hint about >> which TLS methods might be used (e.g., "x509" or "srp"), whereas no SDP >> methods are defined for that functionality. I could work with the >> authors of DTLS-SRTP to include something along these lines. > > How do they solve the problem of bootstrapping trust? We could force > x509 if we talk to SIP clients, e.g. a SIP client will always support > this methid and has no fallback. I know, that sucks. I'm not sure I understand what the advantage of this functionality is in any case. -Ekr From mcgrew at cisco.com Mon Mar 2 16:51:44 2009 From: mcgrew at cisco.com (David McGrew) Date: Mon, 2 Mar 2009 14:51:44 -0800 Subject: [Security] XTLS and DTLS-SRTP In-Reply-To: <49AC57B6.8050109@stpeter.im> References: <49AC57B6.8050109@stpeter.im> Message-ID: <487D1CE6-EEF1-4403-B769-6E74D5D2588E@cisco.com> Hi Peter, On Mar 2, 2009, at 2:03 PM, Peter Saint-Andre wrote: > [sent to security at xmpp.org with cc's for non-list-members] > > The "XTLS" specification that Dirk Meyer and I have been working on > enables two entities to establish TLS over a Jingle transport method > before exchanging application data over the transport: > > http://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-00 > > The primary use case we've had in mind is secure end-to-end XML > streams > over a streaming transport such as in-band bytestreams (mainly for the > purpose of encrypted text chat). However, this protocol could also be > used to secure a datagram transport such as UDP via DTLS (instead of a > streaming transport via TLS). In fact the signalling is quite > similar to > DTLS-SRTP: > > http://tools.ietf.org/html/draft-ietf-sip-dtls-srtp-framework > > http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp > > In particular, the XTLS element would map to the SDP > a=fingerprint line, as shown in the following pseudo-examples (I have > not checked all the specifics so there might not be a complete mapping > between the XMPP and the SIP+SDP). > > id='xn28s7gk' > to='juliet at capulet.lit/balcony' > type='set'> > > action='session-initiate' > initiator='romeo at montague.lit/orchard' > sid='a73sjjvkla37jfea'> > > > > generation='0' > id='a9j3mnbtu1' > ip='10.1.1.104' > port='13540'/> > > > RomeoX509CertificateHash > > > > > > > > INVITE sip:juliet at capulet.lit SIP/2.0 > To: > From: ;tag=843c7b0b > Via: SIP/2.0/TLS ua1.montague.lit;branch=z9hG4bK-0e53sadfkasldkfj > Contact: > Call-ID: 6076913b1c39c212 at REVMTEpG > CSeq: 1 INVITE > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, UPDATE > Max-Forwards: 70 > Content-Type: application/sdp > Content-Length: xxxx > Supported: from-change > > v=0 > o=- 1181923068 1181923196 IN IP4 ua1.montague.lit > s=example1 > c=IN IP4 ua1.montague.lit > a=setup:actpass > a=fingerprint: SHA-1 RomeoX509CertificateHash > t=0 0 > m=audio 6056 RTP/AVP 0 > a=sendrecv > a=tcap:1 UDP/TLS/RTP/SAVP RTP/AVP > a=pcfg:1 t=1 > > I see a few differences here that we might want to harmonize: > > 1. The a=fingerprint line specifies the hashing algorithm used, > whereas > the XTLS element does not. We could easily add an > 'algo' > attribute to the element. I think that's a good idea for crypto-agility (at least). > > > 2. The XTLS element enables a party to provide a hint > about > which TLS methods might be used (e.g., "x509" or "srp"), whereas no > SDP > methods are defined for that functionality. I could work with the > authors of DTLS-SRTP to include something along these lines. What would we recommend that a receiver of the element do, based on this hint? Not attempt a connection if it doesn't support the desired method, or if it lacks a cert or password to provide proper authentication? best, David > > > Feedback is welcome. I will look into incorporating some of this > thinking into the Jingle RTP Sessions specification: > > http://xmpp.org/extensions/xep-0167.html > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > From stpeter at stpeter.im Mon Mar 2 17:18:55 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Mon, 02 Mar 2009 16:18:55 -0700 Subject: [Security] [Fwd: I-D Action:draft-meyer-xmpp-e2e-encryption-00.txt] Message-ID: <49AC695F.8070706@stpeter.im> FYI (I forgot to forward this to the security at xmpp.org list). -------- Original Message -------- Subject: I-D Action:draft-meyer-xmpp-e2e-encryption-00.txt Date: Sat, 28 Feb 2009 11:15:01 -0800 (PST) From: Internet-Drafts at ietf.org Reply-To: internet-drafts at ietf.org To: i-d-announce at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensible Messaging and Presence Protocol (XMPP) End-to-End Encryption Using Transport Layer Security ("XTLS") Author(s) : D. Meyer, P. Saint-Andre Filename : draft-meyer-xmpp-e2e-encryption-00.txt Pages : 23 Date : 2009-02-28 This document specifies "XTLS", a protocol for end-to-end encryption of Extensible Messaging and Presence Protocol (XMPP) traffic via an application-level usage of Transport Layer Security (TLS). XTLS treats the end-to-end exchange of XML stanzas as a virtual transport and uses TLS to secure that transport, thus enabling XMPP entities to communicate in a way that is designed to prevent eavesdropping, tampering, and forgery of XML stanzas. The protocol can be used for secure end-to-end messaging as well as any others application such as file transfer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-meyer-xmpp-e2e-encryption-00.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090302/0a0b8a48/attachment-0001.bin From stpeter at stpeter.im Mon Mar 2 17:19:19 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Mon, 02 Mar 2009 16:19:19 -0700 Subject: [Security] [Fwd: I-D Action:draft-meyer-xmpp-sasl-cert-management-00.txt] Message-ID: <49AC6977.6060106@stpeter.im> FYI (I forgot to forward this to the security at xmpp.org list). -------- Original Message -------- Subject: I-D Action:draft-meyer-xmpp-sasl-cert-management-00.txt Date: Sat, 28 Feb 2009 11:15:01 -0800 (PST) From: Internet-Drafts at ietf.org Reply-To: internet-drafts at ietf.org To: i-d-announce at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Management and Use of Client Certificates for the Extensible Messaging and Presence Protocol (XMPP) Author(s) : D. Meyer, P. Saint-Andre Filename : draft-meyer-xmpp-sasl-cert-management-00.txt Pages : 15 Date : 2009-02-28 This document defines methods for managing and using client certificates in the Extensible Messaging and Presence Protocol (XMPP). These methods, which make use of the EXTERNAL mechanism of the Simple Authentication and Security Layer (SASL) protocol, enable an XMPP client to log in to an XMPP server without providing a password. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-meyer-xmpp-sasl-cert-management-00.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090302/fdf6fd78/attachment.bin From stpeter at stpeter.im Tue Mar 3 13:05:25 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 03 Mar 2009 12:05:25 -0700 Subject: [Security] where do the security bits belong? Message-ID: <49AD7F75.1080809@stpeter.im> I've started reviewing all the Jingle specifications for one final read-through, and it struck me that the security-related bits are now in draft-meyer-xmpp-e2e-encryption: http://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption The primary driver for this work is indeed end-to-end encryption of XMPP traffic as explained in that I-D, but the element could also be used to provide a "security context" (not sure if that is the proper phrase) for a streaming or datagram transport that is used with any application type. So there really are three different moving parts here: 1. The application type. The urn:xmpp:jingle:apps:xmlstream:0 namespace from the I-D defines a new application type for end-to-end XML streams, which we strongly recommend that you do over a secured transport (else what is the point other than escaping the tyranny of rate limits?). However, you could also do file transfer (XEP-0234) or VoIP (XEP-0167) or any other Jingle application type over a secured transport. 2. The transport. As explained in XEP-0166, the transport can be streaming (in-band bytestreams, SOCKS5 bytestreams, ice-tcp, etc.) or datagram (raw UDP, ice-udp, etc.) Adding "XTLS" into the mix changes the dynamics of session negotiation, which is pretty core to Jingle as a negotiation framework. 3. The security context (a.k.a. "XTLS"). Until now, no Jingle transport methods had a security context (or, to be precise, they had a null context). But the urn:xmpp:jingle:security:xtls:0 namespace defined in the I-D adds a element to any Jingle negotiation, which can be used to establish a security context via "XTLS", i.e., TLS for a streaming transport and DTLS for a datagram transport. My question is, where does the definition of XLTS really belong? It feels odd *not* to define it in XEP-0166, since that is the core Jingle spec and the addition of security contexts changes how sessions are negotiated. If we did that, draft-meyer-xmpp-e2e-encryption would be rather brief because it would define only the combination of the end-to-end XML streams application type, a streaming transport (most simply in-band bytestreams), and a security context. On the other hand, if we define security contexts in an Internet-Draft then it is more likely to receive proper security review within the IETF. However, at that point it seems that we might be bringing in a whole raft of dependencies. Perhaps that is manageable (I don't think it's appropriate to suddenly move all of the Jingle specifications to an XMPP WG!), but I want to make sure that we can manage this work in such a way that we receive the proper security reviews for XTLS without burdening the IETF with masses of new work. Finally, somewhat of an aesthetic point is that I'd really like to have only one document that defines end-to-end encryption of XMPP traffic, rather than forcing a developer to read a spec on end-to-end XML streams, a spec on Jingle security contexts, and so on. Perhaps that is not so important in the end, but I'd appreciate feedback about it from client developers. Thoughts? Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090303/93c18873/attachment.bin From justin at affinix.com Tue Mar 3 13:42:50 2009 From: justin at affinix.com (Justin Karneges) Date: Tue, 3 Mar 2009 11:42:50 -0800 Subject: [Security] where do the security bits belong? In-Reply-To: <49AD7F75.1080809@stpeter.im> References: <49AD7F75.1080809@stpeter.im> Message-ID: <200903031142.50825.justin@affinix.com> On Tuesday 03 March 2009 11:05:25 Peter Saint-Andre wrote: > My question is, where does the definition of XLTS really belong? > > It feels odd *not* to define it in XEP-0166, since that is the core > Jingle spec and the addition of security contexts changes how sessions > are negotiated. I think it's fine to put the transport security bits into XEP-0166. I also suggest dropping the term "XTLS". That name used to have a meaning, but today it is misleading, and I don't think we need a special name anyway. Security in Jingle can simply be called just that: Jingle Security. Or Jingle Transport Security. Whatever name you happen to use for the new section in XEP-0166. :) > On the other hand, if we define security contexts in an Internet-Draft > then it is more likely to receive proper security review within the > IETF. However, at that point it seems that we might be bringing in a > whole raft of dependencies. Perhaps that is manageable (I don't think > it's appropriate to suddenly move all of the Jingle specifications to an > XMPP WG!), but I want to make sure that we can manage this work in such > a way that we receive the proper security reviews for XTLS without > burdening the IETF with masses of new work. No matter how you slice it, anyone doing a security review will have to read the whole of Jingle. So unless you plan to publish the entire thing as IETF material, I'd say it doesn't matter much what you do otherwise (such as publishing just an e2e XML streams spec). -Justin From stpeter at stpeter.im Tue Mar 3 16:57:10 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 03 Mar 2009 15:57:10 -0700 Subject: [Security] where do the security bits belong? In-Reply-To: <200903031142.50825.justin@affinix.com> References: <49AD7F75.1080809@stpeter.im> <200903031142.50825.justin@affinix.com> Message-ID: <49ADB5C6.20204@stpeter.im> Justin Karneges wrote: > On Tuesday 03 March 2009 11:05:25 Peter Saint-Andre wrote: >> My question is, where does the definition of XLTS really belong? >> >> It feels odd *not* to define it in XEP-0166, since that is the core >> Jingle spec and the addition of security contexts changes how sessions >> are negotiated. > > I think it's fine to put the transport security bits into XEP-0166. That feels like the right approach to me (why send someone off to an I-D or RFC to read about Jingle Security when they're reading XEP-0166?). > I also suggest dropping the term "XTLS". That name used to have a meaning, > but today it is misleading, and I don't think we need a special name anyway. Yeah, probably. I used it here to provide continuity, but I agree that it is confusing because specifying transport security preconditions in Jingle is not analogous to DTLS (the only other *TLS technology that I know of). > Security in Jingle can simply be called just that: Jingle Security. Or > Jingle Transport Security. Whatever name you happen to use for the new > section in XEP-0166. :) Right. I think "Transport Security Preconditions" is fine. Then we need each transport definition to specify how it handles those. >> On the other hand, if we define security contexts in an Internet-Draft >> then it is more likely to receive proper security review within the >> IETF. However, at that point it seems that we might be bringing in a >> whole raft of dependencies. Perhaps that is manageable (I don't think >> it's appropriate to suddenly move all of the Jingle specifications to an >> XMPP WG!), but I want to make sure that we can manage this work in such >> a way that we receive the proper security reviews for XTLS without >> burdening the IETF with masses of new work. > > No matter how you slice it, anyone doing a security review will have to read > the whole of Jingle. Well, at least they would need to understand XEP-0166 and look at how several of the various transport specs handle security preconditions. > So unless you plan to publish the entire thing as IETF > material, Not a good idea, I think. > I'd say it doesn't matter much what you do otherwise (such as > publishing just an e2e XML streams spec). It would certainly make draft-meyer-xmpp-e2e-encryption quite a bit shorter. Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090303/b7cdc119/attachment-0001.bin From stpeter at stpeter.im Tue Mar 3 17:29:43 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Tue, 03 Mar 2009 16:29:43 -0700 Subject: [Security] where do the security bits belong? In-Reply-To: <49ADB5C6.20204@stpeter.im> References: <49AD7F75.1080809@stpeter.im> <200903031142.50825.justin@affinix.com> <49ADB5C6.20204@stpeter.im> Message-ID: <49ADBD67.5040902@stpeter.im> Peter Saint-Andre wrote: > Justin Karneges wrote: > >> I also suggest dropping the term "XTLS". That name used to have a meaning, >> but today it is misleading, and I don't think we need a special name anyway. > > Yeah, probably. I used it here to provide continuity, but I agree that > it is confusing because specifying transport security preconditions in > Jingle is not analogous to DTLS (the only other *TLS technology that I > know of). > >> Security in Jingle can simply be called just that: Jingle Security. Or >> Jingle Transport Security. Whatever name you happen to use for the new >> section in XEP-0166. :) > > Right. I think "Transport Security Preconditions" is fine. Then we need > each transport definition to specify how it handles those. A further thought: are there any security preconditions other than TLS? Given that we can secure any streaming transport via TLS and that we can secure any datagram transport via DTLS, do we need extensibility here of the kind we have with application types and transport methods? I think not. Sure, in the far future it is possible that someone will design a new technology that supersedes Transport Layer Security for both streaming connections and datagram associations, but at that point we could look into make the security preconditions mechanisms extensible. I don't see that happening anytime soon. Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090303/32ac69cf/attachment.bin From dmeyer at tzi.de Wed Mar 4 03:40:51 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Wed, 04 Mar 2009 10:40:51 +0100 Subject: [Security] XTLS and DTLS-SRTP In-Reply-To: (Eric Rescorla's message of "Mon\, 2 Mar 2009 14\:35\:31 -0800") References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> Message-ID: <87eixdvd5o.fsf@phex.sachmittel.de> Hi, sorry for the delay, I was busy the last two days. Eric Rescorla wrote: >>> 2. The XTLS element enables a party to provide a hint about >>> which TLS methods might be used (e.g., "x509" or "srp"), whereas no SDP >>> methods are defined for that functionality. I could work with the >>> authors of DTLS-SRTP to include something along these lines. >> >> How do they solve the problem of bootstrapping trust? We could force >> x509 if we talk to SIP clients, e.g. a SIP client will always support >> this methid and has no fallback. I know, that sucks. > > I'm not sure I understand what the advantage of this functionality is in > any case. The idea behind the method exchange is to know in advance if X.509 certificates will work or if we need SRP. For SRP the client has to ask the user while X.509 works without any user interaction. We could just try X.509 and do an SRP re-keying later if we can not verify the certificates. But at least my TLS lib does not support this. Which reminds me of a problem: I talked to Klaus yesterday because we both want to implement XTLS and do some interopts. He uses DotNet and the DotNet TLS layer does not support SRP. Before Dave jumps in and promotes channel bindings: they won't work either. As far as I understand channel bindings you need the TLS Finished messages for it. DotNet has no support for this either. What we need is a way to make the channel secure WITHOUT any special requirements from the TLS lib. o It should be secure with a short password (e.g. four digests on a keypad of a mobile phone) o It MUST detect the end-to-end characteristic of the TLS stream by either: 1. Detect if there is a MITM, or 2. Exchange the X.509 certificates used end-to-en I made something up that can provide this. But I'm not an expert, I may have missed something. Is there anything in the IETF that could help us? Dirk -- In the Beginning It was a nice day. -- (Terry Pratchett & Neil Gaiman, Good Omens) From dmeyer at tzi.de Wed Mar 4 03:48:40 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Wed, 04 Mar 2009 10:48:40 +0100 Subject: [Security] where do the security bits belong? In-Reply-To: <49AD7F75.1080809@stpeter.im> (Peter Saint-Andre's message of "Tue\, 03 Mar 2009 12\:05\:25 -0700") References: <49AD7F75.1080809@stpeter.im> Message-ID: <878wnlvcsn.fsf@phex.sachmittel.de> Peter Saint-Andre wrote: > I've started reviewing all the Jingle specifications for one final > read-through, and it struck me that the security-related bits are now in > draft-meyer-xmpp-e2e-encryption: > > http://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption > > The primary driver for this work is indeed end-to-end encryption of XMPP > traffic as explained in that I-D, but the element could also > be used to provide a "security context" (not sure if that is the proper > phrase) for a streaming or datagram transport that is used with any > application type. Yes > So there really are three different moving parts here: > > 1. The application type. The urn:xmpp:jingle:apps:xmlstream:0 namespace > from the I-D defines a new application type for end-to-end XML streams, > which we strongly recommend that you do over a secured transport (else > what is the point other than escaping the tyranny of rate limits?). > However, you could also do file transfer (XEP-0234) or VoIP (XEP-0167) > or any other Jingle application type over a secured transport. That's why I splitted the secure channel from the e2e streams in the draft. > 2. The transport. As explained in XEP-0166, the transport can be > streaming (in-band bytestreams, SOCKS5 bytestreams, ice-tcp, etc.) or > datagram (raw UDP, ice-udp, etc.) Adding "XTLS" into the mix changes the > dynamics of session negotiation, which is pretty core to Jingle as a > negotiation framework. Does it change Jingle? Or does it only change Jingle RTP? > 3. The security context (a.k.a. "XTLS"). Until now, no Jingle transport > methods had a security context (or, to be precise, they had a null > context). But the urn:xmpp:jingle:security:xtls:0 namespace defined in > the I-D adds a element to any Jingle negotiation, which can > be used to establish a security context via "XTLS", i.e., TLS for a > streaming transport and DTLS for a datagram transport. > > My question is, where does the definition of XLTS really belong? > > It feels odd *not* to define it in XEP-0166, since that is the core > Jingle spec and the addition of security contexts changes how sessions > are negotiated. As I see it, is an add-on to Jingle. > If we did that, draft-meyer-xmpp-e2e-encryption would be > rather brief because it would define only the combination of the > end-to-end XML streams application type, a streaming transport (most > simply in-band bytestreams), and a security context. IMHO that would not justify an IETF draft. > On the other hand, if we define security contexts in an Internet-Draft > then it is more likely to receive proper security review within the > IETF. However, at that point it seems that we might be bringing in a > whole raft of dependencies. Perhaps that is manageable People told me that an external dependency is not a problem. I strongly feel that XTLS and e2e streams belong into the draft. As you said, people who know MUCH more about security may look at it now. IMHO that is the important part. I see no problem with file-transfer refering to the draft. > (I don't think it's appropriate to suddenly move all of the Jingle > specifications to an XMPP WG!), No, we should not do that. If we start with that, what about XEP-0030? We don't want to give up XEPs from drafts without reason. > but I want to make sure that we can manage this work in such a way > that we receive the proper security reviews for XTLS without burdening > the IETF with masses of new work. IMHO the draft specifies the core of e2e security and one simple use case (e2e streams). The examples show as much Jingle as needed to understand it. > Finally, somewhat of an aesthetic point is that I'd really like to have > only one document that defines end-to-end encryption of XMPP traffic, > rather than forcing a developer to read a spec on end-to-end XML > streams, a spec on Jingle security contexts, and so on. Perhaps that is > not so important in the end, but I'd appreciate feedback about it from > client developers. It would be nice to have only one doc, but that would mean to merge Jingle into the doc. I loud NO from me. Dirk -- The 50-50-90 rule: Any time you have a 50-50 chance of getting something right, there's a 90% probability you'll get it wrong. From dmeyer at tzi.de Wed Mar 4 03:50:21 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Wed, 04 Mar 2009 10:50:21 +0100 Subject: [Security] where do the security bits belong? In-Reply-To: <49ADB5C6.20204@stpeter.im> (Peter Saint-Andre's message of "Tue\, 03 Mar 2009 15\:57\:10 -0700") References: <49AD7F75.1080809@stpeter.im> <200903031142.50825.justin@affinix.com> <49ADB5C6.20204@stpeter.im> Message-ID: <873adtvcpu.fsf@phex.sachmittel.de> Peter Saint-Andre wrote: > Justin Karneges wrote: >> I'd say it doesn't matter much what you do otherwise (such as >> publishing just an e2e XML streams spec). > > It would certainly make draft-meyer-xmpp-e2e-encryption quite a bit shorter. Will the result justify a draft? It will simply say that you can open a stream over Jingle and points to Jingle. Dirk -- Voodoo Programming: Things programmers do that they know shouldn't work but they try anyway, and which sometimes actually work, such as recompiling everything. -- Karl Lehenbauer From ekr at rtfm.com Wed Mar 4 09:17:33 2009 From: ekr at rtfm.com (Eric Rescorla) Date: Wed, 4 Mar 2009 07:17:33 -0800 Subject: [Security] XTLS and DTLS-SRTP In-Reply-To: <87eixdvd5o.fsf@phex.sachmittel.de> References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> Message-ID: On Wed, Mar 4, 2009 at 1:40 AM, Dirk Meyer wrote: > Hi, > > sorry for the delay, I was busy the last two days. > > Eric Rescorla wrote: >>>> 2. The XTLS element enables a party to provide a hint about >>>> which TLS methods might be used (e.g., "x509" or "srp"), whereas no SDP >>>> methods are defined for that functionality. I could work with the >>>> authors of DTLS-SRTP to include something along these lines. >>> >>> How do they solve the problem of bootstrapping trust? We could force >>> x509 if we talk to SIP clients, e.g. a SIP client will always support >>> this methid and has no fallback. I know, that sucks. >> >> I'm not sure I understand what the advantage of this functionality is in >> any case. > > The idea behind the method exchange is to know in advance if X.509 > certificates will work or if we need SRP. For SRP the client has to ask > the user while X.509 works without any user interaction. > > We could just try X.509 and do an SRP re-keying later if we can not > verify the certificates. But at least my TLS lib does not support > this. Which reminds me of a problem: I talked to Klaus yesterday because > we both want to implement XTLS and do some interopts. He uses DotNet and > the DotNet TLS layer does not support SRP. Before Dave jumps in and > promotes channel bindings: they won't work either. As far as I > understand channel bindings you need the TLS Finished messages for > it. DotNet has no support for this either. > > What we need is a way to make the channel secure WITHOUT any special > requirements from the TLS lib. > > o It should be secure with a short password (e.g. four digests on a > ?keypad of a mobile phone) > o It MUST detect the end-to-end characteristic of the TLS stream by > ?either: > ?1. Detect if there is a MITM, or > ?2. Exchange the X.509 certificates used end-to-en > > I made something up that can provide this. But I'm not an expert, I may > have missed something. Is there anything in the IETF that could help us? I must have lost the thread of what you're trying to accomplish here somewhere. The basic idea behind DTLS-SRTP (and connected identity) is that you trust the signalling channel (SIP or the XMPP channel you're using to set up the direct connection) to accurately convey the end-party's certificate fingerprints so they can be conveyed. There's no real intention to verify them independently of that because the niotion is that they are verified by RFC 4474 signatures from the proxy responsible for the relevant section of namespace. Now, that isn't to say that if you and I had some independent mechanism for verifying each other's identities we couldn't use it, but it's not the main thing we were trying to achieve because we figured that wasn't the common case. So, I'm not sure you need any external validation, especially if you use key continuity in the future. With that said, it's quite straightforward to build such a system usng information provided by nearly any TLS library: cryptographically bind the passphrase/PIN to the certificates exchanged by either side. Of course, this entails running the authentication exchange in the application layer which is a pain since TLS already has one, but... -Ekr From dmeyer at tzi.de Wed Mar 4 10:31:27 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Wed, 04 Mar 2009 17:31:27 +0100 Subject: [Security] XTLS and DTLS-SRTP In-Reply-To: (Eric Rescorla's message of "Wed\, 4 Mar 2009 07\:17\:33 -0800") References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> Message-ID: <87r61duu5c.fsf@phex.sachmittel.de> Eric Rescorla wrote: > I must have lost the thread of what you're trying to accomplish here somewhere. > The basic idea behind DTLS-SRTP (and connected identity) is that you trust > the signalling channel (SIP or the XMPP channel you're using to set up the > direct connection) to accurately convey the end-party's certificate > fingerprints so they can be conveyed. There's no real intention to > verify them independently of that because the niotion is that they are > verified by RFC 4474 signatures from the proxy responsible for the > relevant section of namespace. If you trust your XMPP server and only want to secure the audio stream against people along the way, it is fine. The e2e streams idea depends on not trusting the server. The idea was to combine this: how to set up a secure RTP stream if you do not trust the server? > we were trying to achieve because we figured that wasn't the common case. > So, I'm not sure you need any external validation, especially if you use > key continuity in the future. At least for e2e streams I need something. For secure audio streams I may not. One idea to make audio streams secure is to start an e2e stream (secure) and negotiate a rtp stream over that connection. In that case you can trust the signaling stream. I hope this makes sense. Dirk -- "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" -- Mike Godwin [www.eff.org] From stpeter at stpeter.im Wed Mar 4 11:47:47 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 04 Mar 2009 10:47:47 -0700 Subject: [Security] XTLS and DTLS-SRTP In-Reply-To: <87r61duu5c.fsf@phex.sachmittel.de> References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> <87r61duu5c.fsf@phex.sachmittel.de> Message-ID: <49AEBEC3.5050509@stpeter.im> On 3/4/09 9:31 AM, Dirk Meyer wrote: > Eric Rescorla wrote: >> I must have lost the thread of what you're trying to accomplish here somewhere. >> The basic idea behind DTLS-SRTP (and connected identity) is that you trust >> the signalling channel (SIP or the XMPP channel you're using to set up the >> direct connection) to accurately convey the end-party's certificate >> fingerprints so they can be conveyed. There's no real intention to >> verify them independently of that because the niotion is that they are >> verified by RFC 4474 signatures from the proxy responsible for the >> relevant section of namespace. Naturally we could define such a mechanism for XMPP, especially given the increasingly wide deployment of server certificates on the network. > If you trust your XMPP server and only want to secure the audio stream > against people along the way, it is fine. The e2e streams idea depends > on not trusting the server. The idea was to combine this: how to set up > a secure RTP stream if you do not trust the server? I think it would be helpful to be clear about what kinds of streams we're talking about. By "e2e stream" we mean an end-to-end XML stream (i.e., encryption of the XMPP signalling channel). When you talk about an RTP stream, that is a media session that goes outside the XMPP channel. >> we were trying to achieve because we figured that wasn't the common case. >> So, I'm not sure you need any external validation, especially if you use >> key continuity in the future. > > At least for e2e streams I need something. For secure audio streams I > may not. One idea to make audio streams secure is to start an e2e stream > (secure) and negotiate a rtp stream over that connection. In that case > you can trust the signaling stream. Right. So in that case, you would first set up an end-to-end XML stream (via draft-meyer-xmpp-e2e-encryption) to establish a secure end-to-end XMPP signalling channel. Then once you have that established, you can use the secured XMPP channel to exchange the signalling messages needed to set up an RTP session (or any other kind of session). Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090304/0806e47e/attachment.bin From dmeyer at tzi.de Wed Mar 4 12:04:37 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Wed, 04 Mar 2009 19:04:37 +0100 Subject: [Security] XTLS and DTLS-SRTP In-Reply-To: <49AEBEC3.5050509@stpeter.im> (Peter Saint-Andre's message of "Wed\, 04 Mar 2009 10\:47\:47 -0700") References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> <87r61duu5c.fsf@phex.sachmittel.de> <49AEBEC3.5050509@stpeter.im> Message-ID: <87ljrlupu2.fsf@phex.sachmittel.de> Peter Saint-Andre wrote: > On 3/4/09 9:31 AM, Dirk Meyer wrote: >> At least for e2e streams I need something. For secure audio streams I >> may not. One idea to make audio streams secure is to start an e2e stream >> (secure) and negotiate a rtp stream over that connection. In that case >> you can trust the signaling stream. > > Right. So in that case, you would first set up an end-to-end XML stream > (via draft-meyer-xmpp-e2e-encryption) to establish a secure end-to-end > XMPP signalling channel. Then once you have that established, you can > use the secured XMPP channel to exchange the signalling messages needed > to set up an RTP session (or any other kind of session). So back to the topic: DTLS-SRP. Do we need it? If we use a secure XML stream to signal Jingle RTP, we can put the password directly in session negotiation and no DTLS is needed. Or did I miss something? Dirk -- Expert, n.: Someone who comes from out of town and shows slides. From stpeter at stpeter.im Wed Mar 4 12:18:48 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 04 Mar 2009 11:18:48 -0700 Subject: [Security] XTLS and DTLS-SRTP In-Reply-To: <87eixdvd5o.fsf@phex.sachmittel.de> References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> Message-ID: <49AEC608.7060708@stpeter.im> On 3/4/09 2:40 AM, Dirk Meyer wrote: > > Eric Rescorla wrote: >>>> 2. The XTLS element enables a party to provide a hint about >>>> which TLS methods might be used (e.g., "x509" or "srp"), whereas no SDP >>>> methods are defined for that functionality. I could work with the >>>> authors of DTLS-SRTP to include something along these lines. >>> How do they solve the problem of bootstrapping trust? We could force >>> x509 if we talk to SIP clients, e.g. a SIP client will always support >>> this methid and has no fallback. I know, that sucks. >> I'm not sure I understand what the advantage of this functionality is in >> any case. > > The idea behind the method exchange is to know in advance if X.509 > certificates will work or if we need SRP. For SRP the client has to ask > the user while X.509 works without any user interaction. Dirk, you also mentioned in a private message that the XMPP client might need to initialize the TLS library in different ways. I don't know enough about existing TLS libraries to weigh in on that. > We could just try X.509 and do an SRP re-keying later if we can not > verify the certificates. But at least my TLS lib does not support > this. Which reminds me of a problem: I talked to Klaus yesterday because > we both want to implement XTLS and do some interopts. He uses DotNet and > the DotNet TLS layer does not support SRP. Before Dave jumps in and > promotes channel bindings: they won't work either. As far as I > understand channel bindings you need the TLS Finished messages for > it. DotNet has no support for this either. > > What we need is a way to make the channel secure WITHOUT any special > requirements from the TLS lib. Ideally, yes. The question is: what counts as a "special requirement"? As far as I know, both OpenSSL and GnuTLS now support SRP. I don't know whether they support channel bindings yet. It might help to make a list of the most common TLS libraries and figure out what features they support now and might support in future releases (e.g., perhaps the DotNet TLS layer will support SRP in the next release -- I have no idea). > o It should be secure with a short password (e.g. four digests on a > keypad of a mobile phone) > o It MUST detect the end-to-end characteristic of the TLS stream by > either: > 1. Detect if there is a MITM, or > 2. Exchange the X.509 certificates used end-to-end > > I made something up that can provide this. I'd prefer not to build something homegrown, but we can work on this at the IETF. > But I'm not an expert, I may > have missed something. Is there anything in the IETF that could help us? I sure hope so. :) Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090304/29a2a897/attachment-0001.bin From dmeyer at tzi.de Wed Mar 4 12:45:55 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Wed, 04 Mar 2009 19:45:55 +0100 Subject: [Security] XTLS and DTLS-SRTP In-Reply-To: <49AEC608.7060708@stpeter.im> (Peter Saint-Andre's message of "Wed\, 04 Mar 2009 11\:18\:48 -0700") References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> <49AEC608.7060708@stpeter.im> Message-ID: <87fxhtunx8.fsf@phex.sachmittel.de> Peter Saint-Andre wrote: > On 3/4/09 2:40 AM, Dirk Meyer wrote: >> >> Eric Rescorla wrote: >>>>> 2. The XTLS element enables a party to provide a hint about >>>>> which TLS methods might be used (e.g., "x509" or "srp"), whereas no SDP >>>>> methods are defined for that functionality. I could work with the >>>>> authors of DTLS-SRTP to include something along these lines. >>>> How do they solve the problem of bootstrapping trust? We could force >>>> x509 if we talk to SIP clients, e.g. a SIP client will always support >>>> this methid and has no fallback. I know, that sucks. >>> I'm not sure I understand what the advantage of this functionality is in >>> any case. >> >> The idea behind the method exchange is to know in advance if X.509 >> certificates will work or if we need SRP. For SRP the client has to ask >> the user while X.509 works without any user interaction. > > Dirk, you also mentioned in a private message that the XMPP client might > need to initialize the TLS library in different ways. I don't know > enough about existing TLS libraries to weigh in on that. My TLS lib (and I guess others) require a certificate for X.509 and a user database for SRP on start-up. So I need the password from the user _before_ I can start the TLS server code. For that, I need to know if we use SRP (I need to ask the user) or not (no user interaction). That reminds me of a bug in the draft: SRP needs a username and a password. We do not need the username stuff, but we need something from the TLS lib. So we should say that the username is the bare JID of the initiator or something like that. It doesn't matter, it could be 'foo', but we need to define something. > Ideally, yes. The question is: what counts as a "special requirement"? > As far as I know, both OpenSSL and GnuTLS now support SRP. I don't know > whether they support channel bindings yet. GnuTLS has support to get the Finished message and Dave wrote that OpenSSL has support for that, too. That is all we need from the TLS lib for SCRAM. > I'd prefer not to build something homegrown I know, I don't like it either > but we can work on this at the IETF. I hope so Dirk -- A morning without coffee is like something without something else. From dave at cridland.net Wed Mar 4 13:14:12 2009 From: dave at cridland.net (Dave Cridland) Date: Wed, 04 Mar 2009 19:14:12 +0000 Subject: [Security] XTLS and DTLS-SRTP In-Reply-To: References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> Message-ID: <6147.1236194052.073456@invsysm1> On Wed Mar 4 15:17:33 2009, Eric Rescorla wrote: > With that said, it's quite straightforward to build such a system > usng > information > provided by nearly any TLS library: cryptographically bind the > passphrase/PIN > to the certificates exchanged by either side. Of course, this > entails running > the authentication exchange in the application layer which is a > pain since > TLS already has one, but... TLS has one defined, and we also have SASL, which we can't use for much the same reasons, annoyingly. It's not too bad, though, we do always have a signalling layer available, at least. So, you're thinking of something like: 0) Initiator and Responder agree on key out of band, or via mutual knowledge. 1) Initiator sends InitiatorNonce, list of Hash functions. 2) Responder sends InitiatorNonce, ResponderNonce, Hash function and HMAC(key, InitiatorNonce + ResponderNonce + list of Hash functions + InitiatorCertificate + ResponderCertificate) 3) Initiator sends ResponderNone, InitiatorNonce, Hash function and HMAC(key, ResponderNonde + InitiatorNonce + list of Hash functions + ResponderCertificate + InitiatorCertificate) Is that safe to run over the XMPP layer unprotected? It looks it to me, but I'm hardly an expert... Dave. -- Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From ekr at rtfm.com Wed Mar 4 13:27:40 2009 From: ekr at rtfm.com (Eric Rescorla) Date: Wed, 4 Mar 2009 11:27:40 -0800 Subject: [Security] XTLS and DTLS-SRTP In-Reply-To: <6147.1236194052.073456@invsysm1> References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> <6147.1236194052.073456@invsysm1> Message-ID: <82790C67-5038-432D-9925-69B8F82F71F0@rtfm.com> On Mar 4, 2009, at 11:14 AM, Dave Cridland wrote: > On Wed Mar 4 15:17:33 2009, Eric Rescorla wrote: >> With that said, it's quite straightforward to build such a system >> usng >> information >> provided by nearly any TLS library: cryptographically bind the >> passphrase/PIN >> to the certificates exchanged by either side. Of course, this >> entails running >> the authentication exchange in the application layer which is a >> pain since >> TLS already has one, but... > > TLS has one defined, and we also have SASL, which we can't use for > much the same reasons, annoyingly. It's not too bad, though, we do > always have a signalling layer available, at least. > > So, you're thinking of something like: > > 0) Initiator and Responder agree on key out of band, or via mutual > knowledge. > > 1) Initiator sends InitiatorNonce, list of Hash functions. > > 2) Responder sends InitiatorNonce, ResponderNonce, Hash function and > HMAC(key, InitiatorNonce + ResponderNonce + list of Hash functions + > InitiatorCertificate + ResponderCertificate) > > 3) Initiator sends ResponderNone, InitiatorNonce, Hash function and > HMAC(key, ResponderNonde + InitiatorNonce + list of Hash functions + > ResponderCertificate + InitiatorCertificate) Well maybe. It's pretty distressing to reinvent all this crypto junk in xmpp, especially if pake/zkpp is required. It seems to me better to have people upgrade their tls stacks Ekr > > Is that safe to run over the XMPP layer unprotected? It looks it to > me, but I'm hardly an expert... > > Dave. > -- > Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From stpeter at stpeter.im Wed Mar 4 13:28:53 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 04 Mar 2009 12:28:53 -0700 Subject: [Security] XTLS and DTLS-SRTP In-Reply-To: <82790C67-5038-432D-9925-69B8F82F71F0@rtfm.com> References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> <6147.1236194052.073456@invsysm1> <82790C67-5038-432D-9925-69B8F82F71F0@rtfm.com> Message-ID: <49AED675.5070603@stpeter.im> On 3/4/09 12:27 PM, Eric Rescorla wrote: > > It's pretty distressing to reinvent all this crypto junk in > xmpp, especially if pake/zkpp is required. It seems to me better to have > people upgrade their tls stacks +1 to that! Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090304/4d223061/attachment.bin From simon at josefsson.org Wed Mar 4 16:20:03 2009 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 04 Mar 2009 23:20:03 +0100 Subject: [Security] XTLS and DTLS-SRTP In-Reply-To: <49AEC608.7060708@stpeter.im> (Peter Saint-Andre's message of "Wed, 04 Mar 2009 11:18:48 -0700") References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> <49AEC608.7060708@stpeter.im> Message-ID: <877i35q6b0.fsf@mocca.josefsson.org> Peter Saint-Andre writes: >> We could just try X.509 and do an SRP re-keying later if we can not >> verify the certificates. But at least my TLS lib does not support >> this. Which reminds me of a problem: I talked to Klaus yesterday because >> we both want to implement XTLS and do some interopts. He uses DotNet and >> the DotNet TLS layer does not support SRP. Before Dave jumps in and >> promotes channel bindings: they won't work either. As far as I >> understand channel bindings you need the TLS Finished messages for >> it. DotNet has no support for this either. >> >> What we need is a way to make the channel secure WITHOUT any special >> requirements from the TLS lib. > > Ideally, yes. The question is: what counts as a "special requirement"? > As far as I know, both OpenSSL and GnuTLS now support SRP. I don't know > whether they support channel bindings yet. It might help to make a list > of the most common TLS libraries and figure out what features they > support now and might support in future releases (e.g., perhaps the > DotNet TLS layer will support SRP in the next release -- I have no idea). I think that would be useful too -- as a TLS implementer it is difficult to know what features applications care about. I added a hook to get the TLS Finished messages (which is used for channel bindings) in GnuTLS some time ago when I suspected that some applications may want it. Having more feedback on what kind of features XMPP wants from TLS libraries will help TLS implementers (at least it will help me), and making the requirements explicit may help the decision on what is the best choice for XMPP too. /Simon From mcgrew at cisco.com Wed Mar 4 16:30:13 2009 From: mcgrew at cisco.com (David McGrew) Date: Wed, 4 Mar 2009 14:30:13 -0800 Subject: [Security] XTLS and DTLS-SRTP In-Reply-To: <87eixdvd5o.fsf@phex.sachmittel.de> References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> Message-ID: <7DBAB69D-CD85-4D22-A440-8A2C325A49B4@cisco.com> Hi Dirk, On Mar 4, 2009, at 1:40 AM, Dirk Meyer wrote: > Hi, > > sorry for the delay, I was busy the last two days. > > Eric Rescorla wrote: >>>> 2. The XTLS element enables a party to provide a hint >>>> about >>>> which TLS methods might be used (e.g., "x509" or "srp"), whereas >>>> no SDP >>>> methods are defined for that functionality. I could work with the >>>> authors of DTLS-SRTP to include something along these lines. >>> >>> How do they solve the problem of bootstrapping trust? We could force >>> x509 if we talk to SIP clients, e.g. a SIP client will always >>> support >>> this methid and has no fallback. I know, that sucks. >> >> I'm not sure I understand what the advantage of this functionality >> is in >> any case. > > The idea behind the method exchange is to know in advance if X.509 > certificates will work or if we need SRP. For SRP the client has to > ask > the user while X.509 works without any user interaction. > > We could just try X.509 and do an SRP re-keying later if we can not > verify the certificates. But at least my TLS lib does not support > this. Which reminds me of a problem: I talked to Klaus yesterday > because > we both want to implement XTLS and do some interopts. He uses DotNet > and > the DotNet TLS layer does not support SRP. Before Dave jumps in and > promotes channel bindings: they won't work either. As far as I > understand channel bindings you need the TLS Finished messages for > it. DotNet has no support for this either. > > What we need is a way to make the channel secure WITHOUT any special > requirements from the TLS lib. > > o It should be secure with a short password (e.g. four digests on a > keypad of a mobile phone) > o It MUST detect the end-to-end characteristic of the TLS stream by > either: > 1. Detect if there is a MITM, or > 2. Exchange the X.509 certificates used end-to-en > > I made something up that can provide this. But I'm not an expert, I > may > have missed something. Is there anything in the IETF that could help > us? > Another option would be to use a certificate enrollment protocol such as CMC or SCEP, which would enable the holder of the password to get a certificate, then to just use the cert as needed. The enrollment protocols use public key encryption of the password and they resist offline dictionary attacks (as does SRP and EKE). If certificates are already an option, this might be a low-impact way to go. David > > Dirk > > -- > In the Beginning > > It was a nice day. > -- (Terry Pratchett & Neil Gaiman, Good Omens) From stpeter at stpeter.im Wed Mar 4 16:56:49 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Wed, 04 Mar 2009 15:56:49 -0700 Subject: [Security] [Fwd: [Council] meeting minutes, 2009-03-04] Message-ID: <49AF0731.5090204@stpeter.im> FYI. -------- Original Message -------- Subject: [Council] meeting minutes, 2009-03-04 Date: Wed, 04 Mar 2009 15:56:20 -0700 From: Peter Saint-Andre Reply-To: XMPP Council To: XMPP Council Results of the XMPP Council meeting held 2009-03-04... Agenda: http://xmpp.org/council/agendas/2009-03-04.html Log: http://logs.jabber.org/council at conference.jabber.org/2009-03-04.html Scribe: Peter Saint-Andre 0. Roll call Present: Dave Cridland, Jack Moffitt, Peter Saint-Andre, Kevin Smith. Absent: Ralph Meijer. Quorum achieved. 1. Agenda bashing None. 2. XEP-0047: In-Band Bytestreams (IBB) Approve version 1.2? Dave, Peter, and Kevin voted +1 in the meeting. Ralph and Jack to vote on the list. 3. Voice and video codecs The Council had a long discussion (with input from various attendees) and reached several rough conclusions: a. It makes sense to move the codec text out of XEP-0167. b. We are really trying to describe two things, which the early proposal labelled "jingle-rtp-mti" conflates: (1) recommended codecs for the sake of interoperability and (2) guidelines to Jingle implementors regarding the state of codec implementation and deployment on the Internet today. c. The voice landscape seems fairly clear, since Speex is fairly mature and widely available, and G.711 is patent-clear at this point. d. The video landscape is more murky, since Theora is not yet as mature or widely deployed as Speex is in the voice world, and H.264 is not patent-clear. e. Therefore one *possible* approach *at this time* is to make Speex and G.711 MUST, Theora SHOULD, and H.264 MAY. However, there is no settled consensus on this yet, and the consensus would change over time (in particular as Theora is more widely deployed). Peter will update / rewrite / rename the proposal currently called "jingle-rtp-mti" to reflect this very rough consensus, but the resulting proposal is best seen as a point of departure for further discussion. 4. Jingle security / e2e encryption The Council (with input mainly from Dirk Meyer) explored where the Jingle security definitions belong -- either in XEP-0166 or in an Internet-Draft. The main driver for this Jingle security work is end-to-end encryption of XMPP "conversations" (not necessarily between humans), but the work will result also in the ability to establish security for any Jingle application type and transport method, such as encrypted file transfer over a streaming transport or DTLS-SRTP over UDP. Peter posed the question of how we would proceed if we were not considering the formation of an XMPP WG. Dirk argued as follows: a. we would probably still define a separate Jingle Security spec (not put this into XEP-0166) to retain the same kind of modular approach that we already have in Jingle, where application types and transport methods are defined in separate specs, not in XEP-0166 b. we would update XEP-0166 by defining a "security-info" action and noting the potential inclusion of a element (on the same level as the and elements for application types and transport methods) Very rough consensus that this seems reasonable, but that we will define "Jingle Security" in an Internet-Draft so that it can receive proper security review within the IETF if an XMPP WG is formed. Peter and Dirk to pursue this line of thinking further and perhaps update XEP-0166 and draft-meyer-xmpp-e2e-encryption accordingly. 5. Other business Brief mention was made of efforts by Marcus Lundblad and Olivier Goffart to update http://xmpp.org/extensions/inbox/file-preview.html using the Bits of Binary protocol (XEP-0221); they might have something ready for the Council to consider at the next meeting. 6. Next meeting Wednesday, March 11 @ 20:00 UTC in xmpp:council at conference.jabber.org (visit http://xmpp.org/xsf/XSF.ics to load it into your calendar). Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090304/5260a9a8/attachment.bin From dmeyer at tzi.de Thu Mar 5 07:48:22 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Thu, 05 Mar 2009 14:48:22 +0100 Subject: [Security] TLS Libraries (was: XTLS and DTLS-SRTP) In-Reply-To: <877i35q6b0.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Wed\, 04 Mar 2009 23\:20\:03 +0100") References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> <49AEC608.7060708@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> Message-ID: <87wsb4t715.fsf_-_@phex.sachmittel.de> Simon Josefsson wrote: > Having more feedback on what kind of features XMPP wants from TLS > libraries will help TLS implementers (at least it will help me), and > making the requirements explicit may help the decision on what is the > best choice for XMPP too. For OpenSSL and GnuTLS it is more about features of the bindings. Both libs have SRP and Finished message support for channel-bindings. But the Python bindings (that is what I care about) only support X.509. Well, it is even worse: OpenSSL's Python bindings are old and not updated anymore, GnuTLS does not have real bindings (only some strange ctypes based code flying around without real project homepage). I don't know about Ruby, C#, or any other language. GnuTLS only seems to have suitable Guile bindings -- but seriously, who uses these? If you are part of the GnuTLS team, maybe you can start a campain for good language bindings. The lack of bindings is why many people prefer OpenSSL. Add at least good support for Python and Ruby. Many XMPP client libs are written in scripting languages. Dirk -- ACK and you shall receive. From dave at cridland.net Thu Mar 5 08:04:51 2009 From: dave at cridland.net (Dave Cridland) Date: Thu, 05 Mar 2009 14:04:51 +0000 Subject: [Security] TLS Libraries (was: XTLS and DTLS-SRTP) In-Reply-To: <87wsb4t715.fsf_-_@phex.sachmittel.de> References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> <49AEC608.7060708@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> Message-ID: <20694.1236261891.547941@invsysm1> On Thu Mar 5 13:48:22 2009, Dirk Meyer wrote: > For OpenSSL and GnuTLS it is more about features of the bindings. > Both > libs have SRP and Finished message support for channel-bindings. > But the > Python bindings (that is what I care about) only support X.509. My fork has access to channel bindings, as well as other stuff (like running TLS over arbitrary file-protocol Python objects). Catch me online and I'll point you to it. Dave. -- Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From stpeter at stpeter.im Thu Mar 5 09:02:15 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 05 Mar 2009 08:02:15 -0700 Subject: [Security] TLS Libraries In-Reply-To: <87wsb4t715.fsf_-_@phex.sachmittel.de> References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> <49AEC608.7060708@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> Message-ID: <49AFE977.6040104@stpeter.im> On 3/5/09 6:48 AM, Dirk Meyer wrote: > Simon Josefsson wrote: >> Having more feedback on what kind of features XMPP wants from TLS >> libraries will help TLS implementers (at least it will help me), and >> making the requirements explicit may help the decision on what is the >> best choice for XMPP too. > > For OpenSSL and GnuTLS it is more about features of the bindings. Both > libs have SRP and Finished message support for channel-bindings. But the > Python bindings (that is what I care about) only support X.509. Well, it > is even worse: OpenSSL's Python bindings are old and not updated > anymore, GnuTLS does not have real bindings (only some strange ctypes > based code flying around without real project homepage). > > I don't know about Ruby, C#, or any other language. GnuTLS only seems to > have suitable Guile bindings -- but seriously, who uses these? > > If you are part of the GnuTLS team, maybe you can start a campain for > good language bindings. The lack of bindings is why many people prefer > OpenSSL. Add at least good support for Python and Ruby. Many XMPP client > libs are written in scripting languages. This sounds like a very important effort. Google Summer of Code? Perhaps a collaborative initiative of all the projects that use TLS in various languages? Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090305/7be3ad22/attachment-0001.bin From justin at affinix.com Thu Mar 5 09:43:13 2009 From: justin at affinix.com (Justin Karneges) Date: Thu, 5 Mar 2009 07:43:13 -0800 Subject: [Security] TLS Libraries (was: XTLS and DTLS-SRTP) In-Reply-To: <87wsb4t715.fsf_-_@phex.sachmittel.de> References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> Message-ID: <200903050743.13342.justin@affinix.com> On Thursday 05 March 2009 05:48:22 Dirk Meyer wrote: > Simon Josefsson wrote: > > Having more feedback on what kind of features XMPP wants from TLS > > libraries will help TLS implementers (at least it will help me), and > > making the requirements explicit may help the decision on what is the > > best choice for XMPP too. > > For OpenSSL and GnuTLS it is more about features of the bindings. Both > libs have SRP and Finished message support for channel-bindings. But the > Python bindings (that is what I care about) only support X.509. Well, it > is even worse: OpenSSL's Python bindings are old and not updated > anymore, GnuTLS does not have real bindings (only some strange ctypes > based code flying around without real project homepage). > > I don't know about Ruby, C#, or any other language. GnuTLS only seems to > have suitable Guile bindings -- but seriously, who uses these? This is exactly why I think we should try to find a solution that doesn't require modification to existing TLS APIs. We've already felt enough pain just from XML APIs being inadequate for XMPP streaming (are people done yet homebrewing their parsers with Java/.NET?). Let's not repeat all of that again with TLS, at least for the common scenarios we are targetting. -Justin From ekr at rtfm.com Thu Mar 5 09:53:46 2009 From: ekr at rtfm.com (Eric Rescorla) Date: Thu, 5 Mar 2009 07:53:46 -0800 Subject: [Security] TLS Libraries (was: XTLS and DTLS-SRTP) In-Reply-To: <200903050743.13342.justin@affinix.com> References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <200903050743.13342.justin@affinix.com> Message-ID: On Thu, Mar 5, 2009 at 7:43 AM, Justin Karneges wrote: > On Thursday 05 March 2009 05:48:22 Dirk Meyer wrote: >> Simon Josefsson wrote: >> > Having more feedback on what kind of features XMPP wants from TLS >> > libraries will help TLS implementers (at least it will help me), and >> > making the requirements explicit may help the decision on what is the >> > best choice for XMPP too. >> >> For OpenSSL and GnuTLS it is more about features of the bindings. Both >> libs have SRP and Finished message support for channel-bindings. But the >> Python bindings (that is what I care about) only support X.509. Well, it >> is even worse: OpenSSL's Python bindings are old and not updated >> anymore, GnuTLS does not have real bindings (only some strange ctypes >> based code flying around without real project homepage). >> >> I don't know about Ruby, C#, or any other language. GnuTLS only seems to >> have suitable Guile bindings -- but seriously, who uses these? > > This is exactly why I think we should try to find a solution that doesn't > require modification to existing TLS APIs. ?We've already felt enough pain > just from XML APIs being inadequate for XMPP streaming (are people done yet > homebrewing their parsers with Java/.NET?). ?Let's not repeat all of that > again with TLS, at least for the common scenarios we are targetting. This is of course reasonable, but if the solution involves writing a whole bunch of new crypto code in XMPP that seems undesirable as well, no? -Ekr From simon at josefsson.org Thu Mar 5 10:17:15 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 05 Mar 2009 17:17:15 +0100 Subject: [Security] TLS Libraries In-Reply-To: <87wsb4t715.fsf_-_@phex.sachmittel.de> (Dirk Meyer's message of "Thu, 05 Mar 2009 14:48:22 +0100") References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> <49AEC608.7060708@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> Message-ID: <87ocwgndv8.fsf@mocca.josefsson.org> Dirk Meyer writes: > Simon Josefsson wrote: >> Having more feedback on what kind of features XMPP wants from TLS >> libraries will help TLS implementers (at least it will help me), and >> making the requirements explicit may help the decision on what is the >> best choice for XMPP too. > > For OpenSSL and GnuTLS it is more about features of the bindings. Ah. > Both libs have SRP and Finished message support for > channel-bindings. But the Python bindings (that is what I care about) > only support X.509. Well, it is even worse: OpenSSL's Python bindings > are old and not updated anymore, GnuTLS does not have real bindings > (only some strange ctypes based code flying around without real > project homepage). I am aware of two GnuTLS Python bindings: http://pypi.python.org/pypi/python-gnutls/1.1.8 http://www.imperialviolet.org/pygnutls.html Which one are you talking about? My python fu is weak, so I cannot judge how good they are. pyGnuTLS looks rather abandoned, but python-gnutls seems alive (last release 2009-01-13). > I don't know about Ruby, C#, or any other language. GnuTLS only seems to > have suitable Guile bindings -- but seriously, who uses these? > > If you are part of the GnuTLS team, maybe you can start a campain for > good language bindings. The lack of bindings is why many people prefer > OpenSSL. Add at least good support for Python and Ruby. Many XMPP client > libs are written in scripting languages. This is useful feedback, and I wasn't that aware of this. I talked at FOSDEM about GnuTLS and did ask people to write perl bindings, since I noticed there aren't even Perl bindings available. But I will ask people to work on bindings for more languages. Thanks, /Simon From simon at josefsson.org Thu Mar 5 10:19:45 2009 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 05 Mar 2009 17:19:45 +0100 Subject: [Security] TLS Libraries In-Reply-To: <49AFE977.6040104@stpeter.im> (Peter Saint-Andre's message of "Thu, 05 Mar 2009 08:02:15 -0700") References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> <49AEC608.7060708@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <49AFE977.6040104@stpeter.im> Message-ID: <87k574ndr2.fsf@mocca.josefsson.org> Peter Saint-Andre writes: > On 3/5/09 6:48 AM, Dirk Meyer wrote: >> Simon Josefsson wrote: >>> Having more feedback on what kind of features XMPP wants from TLS >>> libraries will help TLS implementers (at least it will help me), and >>> making the requirements explicit may help the decision on what is the >>> best choice for XMPP too. >> >> For OpenSSL and GnuTLS it is more about features of the bindings. Both >> libs have SRP and Finished message support for channel-bindings. But the >> Python bindings (that is what I care about) only support X.509. Well, it >> is even worse: OpenSSL's Python bindings are old and not updated >> anymore, GnuTLS does not have real bindings (only some strange ctypes >> based code flying around without real project homepage). >> >> I don't know about Ruby, C#, or any other language. GnuTLS only seems to >> have suitable Guile bindings -- but seriously, who uses these? >> >> If you are part of the GnuTLS team, maybe you can start a campain for >> good language bindings. The lack of bindings is why many people prefer >> OpenSSL. Add at least good support for Python and Ruby. Many XMPP client >> libs are written in scripting languages. > > This sounds like a very important effort. Google Summer of Code? Perhaps > a collaborative initiative of all the projects that use TLS in various > languages? Sounds good, I would support that effort. I have signed up as GSOC mentor via the GNU project some years, and could do it again this year if someone can develop a good proposal. /Simon From stpeter at stpeter.im Thu Mar 5 10:24:20 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Thu, 05 Mar 2009 09:24:20 -0700 Subject: [Security] TLS Libraries In-Reply-To: <200903050743.13342.justin@affinix.com> References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <200903050743.13342.justin@affinix.com> Message-ID: <49AFFCB4.30809@stpeter.im> On 3/5/09 8:43 AM, Justin Karneges wrote: > On Thursday 05 March 2009 05:48:22 Dirk Meyer wrote: >> Simon Josefsson wrote: >>> Having more feedback on what kind of features XMPP wants from TLS >>> libraries will help TLS implementers (at least it will help me), and >>> making the requirements explicit may help the decision on what is the >>> best choice for XMPP too. >> For OpenSSL and GnuTLS it is more about features of the bindings. Both >> libs have SRP and Finished message support for channel-bindings. But the >> Python bindings (that is what I care about) only support X.509. Well, it >> is even worse: OpenSSL's Python bindings are old and not updated >> anymore, GnuTLS does not have real bindings (only some strange ctypes >> based code flying around without real project homepage). >> >> I don't know about Ruby, C#, or any other language. GnuTLS only seems to >> have suitable Guile bindings -- but seriously, who uses these? > > This is exactly why I think we should try to find a solution that doesn't > require modification to existing TLS APIs. We've already felt enough pain > just from XML APIs being inadequate for XMPP streaming (are people done yet > homebrewing their parsers with Java/.NET?). Let's not repeat all of that > again with TLS, at least for the common scenarios we are targetting. By that reasoning it was stupid for Jeremie to use XML for the original Jabber technologies when he started to design them in 1998 (XML was very new at the time, library support was missing on many platforms, etc.). So let's say we decide that we want to use Secure Remote Password (SRP) in TLS because it has the best combination of security and usability (I'm not making that claim yet, just positing it for the sake of argument). The SRP support in OpenSSL and GnuTLS is quite recent (not yet in all language bindings), support does not yet exist in .NET and some other platforms, etc. If we really think that TLS-SRP is compelling then the solution is to cajole TLS developers, submit patches, whatever we need to do. The same thing goes for channel bindings if we decide to go that route. The "common scenarios we are targetting" for e2e are perhaps not so common because most people think of TLS as being used between a client and a server (a web browser connecting to a web server, an IM client connecting to an IM server), not between two human-controlled peers that need to perform mutual authentication (probably of end-user certs). So it's not clear to me that our scenario is common at all! The "common" case for c2s or s2s with mutual authentication involves X.509 certs. If IM clients generate self-signed certs as we've discussed, then we need a way to do mutual authentication (unless we propose that people take a leap of faith a la SSH). That's not so straightforward, and from our discussion so far seems to require either SRP or channel bindings, or potentially something homegrown (which puts us outside the security mainstream). We could propose the use of CA-issued certs (and we have a CA that could do so), but that has its own set of usability issues, the need for CRLs or OCSP (for which support is also not widespread), etc. The basic problem here is that we're at the cutting edge, and when you do that you're bound to get sliced up a bit. :) Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090305/2b989a95/attachment.bin From justin at affinix.com Thu Mar 5 12:00:36 2009 From: justin at affinix.com (Justin Karneges) Date: Thu, 5 Mar 2009 10:00:36 -0800 Subject: [Security] TLS Libraries In-Reply-To: <49AFFCB4.30809@stpeter.im> References: <49AC57B6.8050109@stpeter.im> <200903050743.13342.justin@affinix.com> <49AFFCB4.30809@stpeter.im> Message-ID: <200903051000.36654.justin@affinix.com> On Thursday 05 March 2009 08:24:20 Peter Saint-Andre wrote: > On 3/5/09 8:43 AM, Justin Karneges wrote: > > This is exactly why I think we should try to find a solution that doesn't > > require modification to existing TLS APIs. We've already felt enough > > pain just from XML APIs being inadequate for XMPP streaming (are people > > done yet homebrewing their parsers with Java/.NET?). Let's not repeat > > all of that again with TLS, at least for the common scenarios we are > > targetting. > > By that reasoning it was stupid for Jeremie to use XML for the original > Jabber technologies when he started to design them in 1998 (XML was very > new at the time, library support was missing on many platforms, etc.). If XML support was hard to come by in 1998, that's a somewhat different issue, because then everyone would have been dragging along their own XML library anyway. Had Jabber been designed in 2002, when XML support was available as a ready-to-use component of most languages and platforms, then yes I'd say it would be smart to try to work within the limits of "standard" XML APIs. Obviously there's a cost/benefit assessment to be made. We often make compromises in the interest of wider adoption. Not that you need to be told anything about consensus and compromise. :) > The "common scenarios we are targetting" for e2e are perhaps not so > common because most people think of TLS as being used between a client > and a server (a web browser connecting to a web server, an IM client > connecting to an IM server), not between two human-controlled peers that > need to perform mutual authentication (probably of end-user certs). So > it's not clear to me that our scenario is common at all! The "common" > case for c2s or s2s with mutual authentication involves X.509 certs. You're right, this is not a common usage of TLS in the general sense. However, cert/password auth between human-controlled peers will be the most common use-case for *us*, and I think it would be best to see if we can accomplish this with off-the-shelf parts. I'd suggest that path be explored, and then we can weigh our options. -Justin From dmeyer at tzi.de Thu Mar 5 15:24:17 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Thu, 05 Mar 2009 22:24:17 +0100 Subject: [Security] TLS Libraries In-Reply-To: (Eric Rescorla's message of "Thu\, 5 Mar 2009 07\:53\:46 -0800") References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <200903050743.13342.justin@affinix.com> Message-ID: <871vtbbr3y.fsf@phex.sachmittel.de> Eric Rescorla wrote: > On Thu, Mar 5, 2009 at 7:43 AM, Justin Karneges wrote: >> This is exactly why I think we should try to find a solution that doesn't >> require modification to existing TLS APIs. ?We've already felt enough pain >> just from XML APIs being inadequate for XMPP streaming (are people done yet >> homebrewing their parsers with Java/.NET?). ?Let's not repeat all of that >> again with TLS, at least for the common scenarios we are targetting. > > This is of course reasonable, but if the solution involves writing a > whole bunch of new crypto code in XMPP that seems undesirable as well, > no? I guess SRP is the way to go. It is supported by OpenSSL and GnuTLS and it only lacks support in some bindings. Instead of writing something outside TLS just for us, writing a patch to the bindings could take the same coding time. Except doing that provides something usefull outside the XMPP community. The same is true for channel bindings: the libs support it and you only need to add SCRAM support + get the Finished messages into the used SASL lib. As for DotNet, J2ME, and friends it is different. They lack SRP support in the core and you can not just patch the lib. On the other hand GnuTLS runs on Windows and is LGPL, so it can be used inside a closed-source application. Creating C# bindings shouldn't be harder than for any other language. Dirk -- If you can't beat your computer at chess, try kickboxing. From ekr at rtfm.com Thu Mar 5 21:33:53 2009 From: ekr at rtfm.com (Eric Rescorla) Date: Thu, 5 Mar 2009 19:33:53 -0800 Subject: [Security] TLS Libraries In-Reply-To: <871vtbbr3y.fsf@phex.sachmittel.de> References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> Message-ID: On Thu, Mar 5, 2009 at 1:24 PM, Dirk Meyer wrote: > Eric Rescorla wrote: >> On Thu, Mar 5, 2009 at 7:43 AM, Justin Karneges wrote: >>> This is exactly why I think we should try to find a solution that doesn't >>> require modification to existing TLS APIs. ?We've already felt enough pain >>> just from XML APIs being inadequate for XMPP streaming (are people done yet >>> homebrewing their parsers with Java/.NET?). ?Let's not repeat all of that >>> again with TLS, at least for the common scenarios we are targetting. >> >> This is of course reasonable, but if the solution involves writing a >> whole bunch of new crypto code in XMPP that seems undesirable as well, >> no? > > I guess SRP is the way to go. It is supported by OpenSSL and GnuTLS and > it only lacks support in some bindings. Instead of writing something > outside TLS just for us, writing a patch to the bindings could take the > same coding time. Except doing that provides something usefull outside > the XMPP community. The same is true for channel bindings: the libs > support it and you only need to add SCRAM support + get the Finished > messages into the used SASL lib. I think it's pretty important to recognize that there is a qualitative difference between SCRAM and SRP that isn't just a matter of what layer it's at. SCRAM is susceptible to offline dictionary attacks, whereas SRP is not. Obviously, you could do something SRP-oid at the app layer, but we really should decide if dictionary attack resistance is an important element. -Ekr From david at banes.org Fri Mar 6 02:16:12 2009 From: david at banes.org (David Banes) Date: Fri, 6 Mar 2009 19:16:12 +1100 Subject: [Security] TLS Libraries In-Reply-To: References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> Message-ID: <4242F59B-32CE-4D68-B7D7-A7389910B1CD@banes.org> On 06/03/2009, at 2:33 PM, Eric Rescorla wrote: > On Thu, Mar 5, 2009 at 1:24 PM, Dirk Meyer wrote: >> Eric Rescorla wrote: >>> On Thu, Mar 5, 2009 at 7:43 AM, Justin Karneges >>> wrote: >>>> This is exactly why I think we should try to find a solution that >>>> doesn't >>>> require modification to existing TLS APIs. We've already felt >>>> enough pain >>>> just from XML APIs being inadequate for XMPP streaming (are >>>> people done yet >>>> homebrewing their parsers with Java/.NET?). Let's not repeat all >>>> of that >>>> again with TLS, at least for the common scenarios we are >>>> targetting. >>> >>> This is of course reasonable, but if the solution involves writing a >>> whole bunch of new crypto code in XMPP that seems undesirable as >>> well, >>> no? >> >> I guess SRP is the way to go. It is supported by OpenSSL and GnuTLS >> and >> it only lacks support in some bindings. Instead of writing something >> outside TLS just for us, writing a patch to the bindings could take >> the >> same coding time. Except doing that provides something usefull >> outside >> the XMPP community. The same is true for channel bindings: the libs >> support it and you only need to add SCRAM support + get the Finished >> messages into the used SASL lib. > > I think it's pretty important to recognize that there is a qualitative > difference > between SCRAM and SRP that isn't just a matter of what layer it's at. > SCRAM is susceptible to offline dictionary attacks, whereas SRP is > not. > Obviously, you could do something SRP-oid at the app layer, but we > really > should decide if dictionary attack resistance is an important element. > > -Ekr re: "if dictionary attack resistance is an important element." It is 'defense in depth.' David. -------------------------------------------------------------------------------------------------------- Email Filtering by Cleartext a Carbon Minimised company - www.cleartext.com -------------------------------------------------------------------------------------------------------- From simon at josefsson.org Fri Mar 6 03:34:33 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 06 Mar 2009 10:34:33 +0100 Subject: [Security] TLS Libraries In-Reply-To: (Eric Rescorla's message of "Thu, 5 Mar 2009 19:33:53 -0800") References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> Message-ID: <87k573m1ue.fsf@mocca.josefsson.org> Eric Rescorla writes: >> I guess SRP is the way to go. It is supported by OpenSSL and GnuTLS and >> it only lacks support in some bindings. Instead of writing something >> outside TLS just for us, writing a patch to the bindings could take the >> same coding time. Except doing that provides something usefull outside >> the XMPP community. The same is true for channel bindings: the libs >> support it and you only need to add SCRAM support + get the Finished >> messages into the used SASL lib. > > I think it's pretty important to recognize that there is a qualitative > difference > between SCRAM and SRP that isn't just a matter of what layer it's at. > SCRAM is susceptible to offline dictionary attacks, whereas SRP is not. > Obviously, you could do something SRP-oid at the app layer, but we really > should decide if dictionary attack resistance is an important element. There is a SRP SASL mechanism: http://www.watersprings.org/pub/id/draft-burdis-cat-srp-sasl-08.txt I believe it has been implemented, but not widely deployed. /Simon From ekr at rtfm.com Fri Mar 6 03:45:19 2009 From: ekr at rtfm.com (Eric Rescorla) Date: Fri, 6 Mar 2009 01:45:19 -0800 Subject: [Security] TLS Libraries In-Reply-To: <87k573m1ue.fsf@mocca.josefsson.org> References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> <87k573m1ue.fsf@mocca.josefsson.org> Message-ID: On Fri, Mar 6, 2009 at 1:34 AM, Simon Josefsson wrote: > Eric Rescorla writes: > >>> I guess SRP is the way to go. It is supported by OpenSSL and GnuTLS and >>> it only lacks support in some bindings. Instead of writing something >>> outside TLS just for us, writing a patch to the bindings could take the >>> same coding time. Except doing that provides something usefull outside >>> the XMPP community. The same is true for channel bindings: the libs >>> support it and you only need to add SCRAM support + get the Finished >>> messages into the used SASL lib. >> >> I think it's pretty important to recognize that there is a qualitative >> difference >> between SCRAM and SRP that isn't just a matter of what layer it's at. >> SCRAM is susceptible to offline dictionary attacks, whereas SRP is not. >> Obviously, you could do something SRP-oid at the app layer, but we really >> should decide if dictionary attack resistance is an important element. > > There is a SRP SASL mechanism: > > http://www.watersprings.org/pub/id/draft-burdis-cat-srp-sasl-08.txt > > I believe it has been implemented, but not widely deployed. Right. Both symmetric and PAKE-based systems can be implemented both at the TLS layer (PSK and SRP), and at the application layer (SASL-{Digest,SCRAM,...} and SASL-SRP). So, this isn't really an argument about which layer things should be done at. I just think it's important to be clear about what various components are bringing to the party. -Ekr From simon at josefsson.org Fri Mar 6 03:54:37 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 06 Mar 2009 10:54:37 +0100 Subject: [Security] TLS Libraries In-Reply-To: (Eric Rescorla's message of "Fri, 6 Mar 2009 01:45:19 -0800") References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> <87k573m1ue.fsf@mocca.josefsson.org> Message-ID: <87bpsfm0wy.fsf@mocca.josefsson.org> Eric Rescorla writes: > On Fri, Mar 6, 2009 at 1:34 AM, Simon Josefsson wrote: >> Eric Rescorla writes: >> >>>> I guess SRP is the way to go. It is supported by OpenSSL and GnuTLS and >>>> it only lacks support in some bindings. Instead of writing something >>>> outside TLS just for us, writing a patch to the bindings could take the >>>> same coding time. Except doing that provides something usefull outside >>>> the XMPP community. The same is true for channel bindings: the libs >>>> support it and you only need to add SCRAM support + get the Finished >>>> messages into the used SASL lib. >>> >>> I think it's pretty important to recognize that there is a qualitative >>> difference >>> between SCRAM and SRP that isn't just a matter of what layer it's at. >>> SCRAM is susceptible to offline dictionary attacks, whereas SRP is not. >>> Obviously, you could do something SRP-oid at the app layer, but we really >>> should decide if dictionary attack resistance is an important element. >> >> There is a SRP SASL mechanism: >> >> http://www.watersprings.org/pub/id/draft-burdis-cat-srp-sasl-08.txt >> >> I believe it has been implemented, but not widely deployed. > > Right. Both symmetric and PAKE-based systems can be implemented > both at the TLS layer (PSK and SRP), and at the application layer > (SASL-{Digest,SCRAM,...} and SASL-SRP). So, this isn't really an > argument about which layer things should be done at. I just think > it's important to be clear about what various components are bringing > to the party. Perhaps what is missing here is a ... threat model. Do we have a list of attacks that XMPP wishes to protect against by using TLS/SASL/etc? I may have missed it, but I think it would help to find a solution if we first agree on what problems there are. /Simon From ekr at rtfm.com Fri Mar 6 04:00:44 2009 From: ekr at rtfm.com (Eric Rescorla) Date: Fri, 6 Mar 2009 02:00:44 -0800 Subject: [Security] TLS Libraries In-Reply-To: <87bpsfm0wy.fsf@mocca.josefsson.org> References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> <87k573m1ue.fsf@mocca.josefsson.org> <87bpsfm0wy.fsf@mocca.josefsson.org> Message-ID: On Fri, Mar 6, 2009 at 1:54 AM, Simon Josefsson wrote: > Perhaps what is missing here is a ... threat model. ?Do we have a list > of attacks that XMPP wishes to protect against by using TLS/SASL/etc? ?I > may have missed it, but I think it would help to find a solution if we > first agree on what problems there are. Hey, that's my line!!! In any case, I totally agree. -Ekr From dave at cridland.net Fri Mar 6 07:04:28 2009 From: dave at cridland.net (Dave Cridland) Date: Fri, 06 Mar 2009 13:04:28 +0000 Subject: [Security] TLS Libraries In-Reply-To: References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> Message-ID: <1289.1236344668.417345@peirce.dave.cridland.net> On Fri Mar 6 03:33:53 2009, Eric Rescorla wrote: > SCRAM is susceptible to offline dictionary attacks, whereas SRP is > not. Indeed so, but... > Obviously, you could do something SRP-oid at the app layer, but we > really > should decide if dictionary attack resistance is an important > element. I don't think it is - we're not talking in terms of a long-term shared-secret, we're talking about an ephemeral secret shared (say) over the phone, used purely to verify a channel, and, by that, optionally the peer's X.509 cert. If an offline dictionary attack can be mounted within the kind of timescales we're talking, then I'm off to buy a tinfoil hat, because those guys have had it right all along... ;-) Dave. -- Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From stpeter at stpeter.im Fri Mar 6 07:10:58 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 06 Mar 2009 06:10:58 -0700 Subject: [Security] TLS Libraries In-Reply-To: <1289.1236344668.417345@peirce.dave.cridland.net> References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> <1289.1236344668.417345@peirce.dave.cridland.net> Message-ID: <49B120E2.5090007@stpeter.im> On 3/6/09 6:04 AM, Dave Cridland wrote: > On Fri Mar 6 03:33:53 2009, Eric Rescorla wrote: > >> Obviously, you could do something SRP-oid at the app layer, but we really >> should decide if dictionary attack resistance is an important element. > > I don't think it is - we're not talking in terms of a long-term > shared-secret, we're talking about an ephemeral secret shared (say) over > the phone, used purely to verify a channel, and, by that, optionally the > peer's X.509 cert. Correct. AFAIK we're making the following assumptions: 1. Everyone has X.509 certs. 2. Some/most X.509 certs are self-signed, not issued by trusted CAs. 3. For the first communication session, the parties need to verify each other's certs. 4. If the certs are self-signed, that could be done by checking the fingerprints via some other/trusted channel (PGP-encrypted email or whatever), but very few people will do that. We don't want folks to take the leap of faith, so we need an ephemeral password-based method. 5. That reduces to either SRP or some kind of SCRAM-ish channel binding. But, yes, we need to define the threat model. Dirk and I will work that into the next version of our proposal. Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090306/7da0f88a/attachment.bin From ekr at rtfm.com Fri Mar 6 08:03:58 2009 From: ekr at rtfm.com (Eric Rescorla) Date: Fri, 6 Mar 2009 06:03:58 -0800 Subject: [Security] TLS Libraries In-Reply-To: <1289.1236344668.417345@peirce.dave.cridland.net> References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> <1289.1236344668.417345@peirce.dave.cridland.net> Message-ID: On Fri, Mar 6, 2009 at 5:04 AM, Dave Cridland wrote: > On Fri Mar ?6 03:33:53 2009, Eric Rescorla wrote: >> >> SCRAM is susceptible to offline dictionary attacks, whereas SRP is not. > > Indeed so, but... > > >> Obviously, you could do something SRP-oid at the app layer, but we really >> should decide if dictionary attack resistance is an important element. > > I don't think it is - we're not talking in terms of a long-term > shared-secret, we're talking about an ephemeral secret shared (say) over the > phone, used purely to verify a channel, and, by that, optionally the peer's > X.509 cert. You're assuming that these aren't separated by a time scale of hours to days. I don' think that's at all safe. > If an offline dictionary attack can be mounted within the kind of timescales > we're talking, then I'm off to buy a tinfoil hat, because those guys have > had it right all along... ;-) I heard suggestions of 4 digit PINs. Those can be bruteforced in less than a second. -Ekr From dave at cridland.net Fri Mar 6 08:39:29 2009 From: dave at cridland.net (Dave Cridland) Date: Fri, 06 Mar 2009 14:39:29 +0000 Subject: [Security] TLS Libraries In-Reply-To: References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> <1289.1236344668.417345@peirce.dave.cridland.net> Message-ID: <1289.1236350369.545250@peirce.dave.cridland.net> On Fri Mar 6 14:03:58 2009, Eric Rescorla wrote: > On Fri, Mar 6, 2009 at 5:04 AM, Dave Cridland > wrote: > > I don't think it is - we're not talking in terms of a long-term > > shared-secret, we're talking about an ephemeral secret shared > (say) over the > > phone, used purely to verify a channel, and, by that, optionally > the peer's > > X.509 cert. > > You're assuming that these aren't separated by a time scale of > hours to > days. I don' think that's at all safe. > > Well, yes. But you can't do an offline dictionary attack on SCRAM until you've witnessed the SCRAM exchange. By which time it's too late to do anything about it. > > If an offline dictionary attack can be mounted within the kind of > timescales > > we're talking, then I'm off to buy a tinfoil hat, because those > guys have > > had it right all along... ;-) > > I heard suggestions of 4 digit PINs. Those can be bruteforced in > less than > a second. Still needs time travel to make this attack work, doesn't it? Dave. -- Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From ekr at rtfm.com Fri Mar 6 08:42:50 2009 From: ekr at rtfm.com (Eric Rescorla) Date: Fri, 6 Mar 2009 06:42:50 -0800 Subject: [Security] TLS Libraries In-Reply-To: <1289.1236350369.545250@peirce.dave.cridland.net> References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> <1289.1236344668.417345@peirce.dave.cridland.net> <1289.1236350369.545250@peirce.dave.cridland.net> Message-ID: On Fri, Mar 6, 2009 at 6:39 AM, Dave Cridland wrote: > On Fri Mar ?6 14:03:58 2009, Eric Rescorla wrote: >> >> On Fri, Mar 6, 2009 at 5:04 AM, Dave Cridland wrote: >> > I don't think it is - we're not talking in terms of a long-term >> > shared-secret, we're talking about an ephemeral secret shared (say) over >> > the >> > phone, used purely to verify a channel, and, by that, optionally the >> > peer's >> > X.509 cert. >> >> You're assuming that these aren't separated by a time scale of hours to >> days. I don' think that's at all safe. >> >> > Well, yes. But you can't do an offline dictionary attack on SCRAM until > you've witnessed the SCRAM exchange. By which time it's too late to do > anything about it. Uh, no. You MITM the initial connection, then wait for one side to offer his proof. You then simulate a failure, crack the password, and move on. Note that if the password is short enough, you can crack it in real time and move on. >> > If an offline dictionary attack can be mounted within the kind of >> > timescales >> > we're talking, then I'm off to buy a tinfoil hat, because those guys >> > have >> > had it right all along... ;-) >> >> I heard suggestions of 4 digit PINs. Those can be bruteforced in less than >> a second. > > Still needs time travel to make this attack work, doesn't it? No. -Ekr From dave at cridland.net Fri Mar 6 08:54:00 2009 From: dave at cridland.net (Dave Cridland) Date: Fri, 06 Mar 2009 14:54:00 +0000 Subject: [Security] TLS Libraries In-Reply-To: References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> <1289.1236344668.417345@peirce.dave.cridland.net> <1289.1236350369.545250@peirce.dave.cridland.net> Message-ID: <1289.1236351240.976798@peirce.dave.cridland.net> On Fri Mar 6 14:42:50 2009, Eric Rescorla wrote: > You MITM the initial connection, then wait for one side to offer his > proof. You then simulate a failure, crack the password, and move > on. Note that if the password is short enough, you can crack it in > real time and move on. Right, I see. Surely if I'm talking to Peter, and arrange a shared secret, and then I find Peter rejects it, I'm going to tell him pretty quickly? I accept it's possible to circumvent, and there'll be issues with hardware doing this, though. > >> I heard suggestions of 4 digit PINs. Those can be bruteforced in > less than > >> a second. > > > > Still needs time travel to make this attack work, doesn't it? > > No. This is certainly going to be harder to deal with - the 4-digit pins are really related to hardware and other such dumb devices. I'd guess that with SRP, the timescales are simply going to be a bit longer, though? Dave. -- Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From ekr at rtfm.com Fri Mar 6 08:58:05 2009 From: ekr at rtfm.com (Eric Rescorla) Date: Fri, 6 Mar 2009 06:58:05 -0800 Subject: [Security] TLS Libraries In-Reply-To: <1289.1236351240.976798@peirce.dave.cridland.net> References: <49AC57B6.8050109@stpeter.im> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> <1289.1236344668.417345@peirce.dave.cridland.net> <1289.1236350369.545250@peirce.dave.cridland.net> <1289.1236351240.976798@peirce.dave.cridland.net> Message-ID: On Fri, Mar 6, 2009 at 6:54 AM, Dave Cridland wrote: > On Fri Mar ?6 14:42:50 2009, Eric Rescorla wrote: >> >> You MITM the initial connection, then wait for one side to offer his >> proof. You then simulate a failure, crack the password, and move >> on. Note that if the password is short enough, you can crack it in >> real time and move on. > > Right, I see. > > Surely if I'm talking to Peter, and arrange a shared secret, and then I find > Peter rejects it, I'm going to tell him pretty quickly? What do you mean rejects it? The attacker simulates a TCP-level failure. Alternately, he just stalls and waits for the client to give up if he can't brute-force the password in time. >> >> I heard suggestions of 4 digit PINs. Those can be bruteforced in less >> >> than >> >> a second. >> > >> > Still needs time travel to make this attack work, doesn't it? >> >> No. > > This is certainly going to be harder to deal with - the 4-digit pins are > really related to hardware and other such dumb devices. I'd guess that with > SRP, the timescales are simply going to be a bit longer, though? I don't understand the question. The whole point of PAKE protocols is that they preclude offline attacks--you need to do a new protocol run to verify every guess. That's very different. -Ekr From dave at cridland.net Fri Mar 6 09:26:12 2009 From: dave at cridland.net (Dave Cridland) Date: Fri, 06 Mar 2009 15:26:12 +0000 Subject: [Security] TLS Libraries In-Reply-To: References: <49AC57B6.8050109@stpeter.im> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> <1289.1236344668.417345@peirce.dave.cridland.net> <1289.1236350369.545250@peirce.dave.cridland.net> <1289.1236351240.976798@peirce.dave.cridland.net> Message-ID: <1289.1236353172.879600@peirce.dave.cridland.net> On Fri Mar 6 14:58:05 2009, Eric Rescorla wrote: > What do you mean rejects it? The attacker simulates a TCP-level > failure. > Alternately, he just stalls and waits for the client to give up if > he can't > brute-force the password in time. Right, well, I think I've made myself look stupid enough for one day, so I'll restrict myself to asking questions. So, we have some potential problems with the use of anything that's subject to an offline dictionary attack. Have you got any figures on timescales for this, and computing power required? I mean, is this something that anyone who hasn't upset the NSA or GCHQ should be concerned about, or are we within reasonable range of someone trying to phish credit card numbers? Dave. -- Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From dmeyer at tzi.de Fri Mar 6 09:45:54 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Fri, 06 Mar 2009 16:45:54 +0100 Subject: [Security] TLS Libraries In-Reply-To: <1289.1236353172.879600@peirce.dave.cridland.net> (Dave Cridland's message of "Fri\, 06 Mar 2009 15\:26\:12 +0000") References: <49AC57B6.8050109@stpeter.im> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> <1289.1236344668.417345@peirce.dave.cridland.net> <1289.1236350369.545250@peirce.dave.cridland.net> <1289.1236351240.976798@peirce.dave.cridland.net> <1289.1236353172.879600@peirce.dave.cridland.net> Message-ID: <87d4cuodsd.fsf@phex.sachmittel.de> Dave Cridland wrote: > Have you got any figures on timescales for this, and computing power > required? I mean, is this something that anyone who hasn't upset the > NSA or GCHQ should be concerned about, or are we within reasonable > range of someone trying to phish credit card numbers? http://tools.ietf.org/html/draft-newman-auth-scram-08 Section 7 The amount of time necessary for this attack depends on the cryptographic hash function selected, the strength of the password and the iteration count supplied by the server. Looking at how SCRAM works, an interation count of 1 and my stupid pin passwords (four digests) I'm sure every laptop today can hack it (there are only 10000 possible passwords). The iteration count is set by the server, so I'm not sure it adds additional security. The MITM will be server for one client, so I guess it is too easy. I'm no security expert, but: A ---- MITM ---- B A thinks it requests the channel-bindings with B but it does so with MITM. It sends a username to MITM and MITM chooses salt and iteration count. AuthMessage := client-first-message + "," + server-first-message + "," + final-client-message-without-proof ClientSignature := HMAC(StoredKey, AuthMessage) ClientProof := ClientKey XOR ClientSignature The MITM must calculate this for every possible StoredKey/ClientKey. Even with an iteration, it can calculate that in advance. It has a dictionary with 10000 entries (pin, StoredKey, ClientKey) and always using the same salt. Therefore the MITM needs to calculate: HMAC(StoredKey, AuthMessage) XOR ClientKey It shouldn't take long to do this 10000 times and compare the result with what the client send as ClientProof. If MITM is done with that, it knows the password to play A to B. Or did I miss something? Alexey, you are the expert here. Dirk -- A good programmer is someone who looks both ways before crossing a one-way street. - Doug Linder From simon at josefsson.org Fri Mar 6 09:49:04 2009 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 06 Mar 2009 16:49:04 +0100 Subject: [Security] TLS Libraries In-Reply-To: <1289.1236353172.879600@peirce.dave.cridland.net> (Dave Cridland's message of "Fri, 06 Mar 2009 15:26:12 +0000") References: <49AC57B6.8050109@stpeter.im> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> <1289.1236344668.417345@peirce.dave.cridland.net> <1289.1236350369.545250@peirce.dave.cridland.net> <1289.1236351240.976798@peirce.dave.cridland.net> <1289.1236353172.879600@peirce.dave.cridland.net> Message-ID: <8763imlki7.fsf@mocca.josefsson.org> Dave Cridland writes: > On Fri Mar 6 14:58:05 2009, Eric Rescorla wrote: >> What do you mean rejects it? The attacker simulates a TCP-level >> failure. >> Alternately, he just stalls and waits for the client to give up if >> he can't >> brute-force the password in time. > > Right, well, I think I've made myself look stupid enough for one day, > so I'll restrict myself to asking questions. > > So, we have some potential problems with the use of anything that's > subject to an offline dictionary attack. > > Have you got any figures on timescales for this, and computing power > required? I mean, is this something that anyone who hasn't upset the > NSA or GCHQ should be concerned about, or are we within reasonable > range of someone trying to phish credit card numbers? SCRAM says to use an iteration count of 128, and due to the salting, that means the attacker needs to perform 128 hashes to test a particular password for one session. 'openssl speed sha1' on my machine does around 1000000 16-byte hashes per second. So the attacker can test around 8000 passwords per second. My /usr/share/dict/american-english contains around 100000 words. So it takes around 13 seconds to go through this dictionary on my laptop. This may not be completely correct, and I may be completely wrong about something, but I hope the magnitude is about right. Btw, this argues that the SCRAM iteration count should really be much higher. RFC 3962 uses 4096 by default but even that is slightly low. /Simon From dmeyer at tzi.de Fri Mar 6 12:00:15 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Fri, 06 Mar 2009 19:00:15 +0100 Subject: [Security] TLS Libraries In-Reply-To: <87ocwgndv8.fsf@mocca.josefsson.org> (Simon Josefsson's message of "Thu\, 05 Mar 2009 17\:17\:15 +0100") References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> <49AEC608.7060708@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <87ocwgndv8.fsf@mocca.josefsson.org> Message-ID: <87ab7ycz0w.fsf@phex.sachmittel.de> Simon Josefsson wrote: > I am aware of two GnuTLS Python bindings: > > http://pypi.python.org/pypi/python-gnutls/1.1.8 > http://www.imperialviolet.org/pygnutls.html > > Which one are you talking about? My python fu is weak, so I cannot > judge how good they are. pyGnuTLS looks rather abandoned, but > python-gnutls seems alive (last release 2009-01-13). I'm talking about python-gnutls. This ctypes stuff feels wrong here. I would prefer "real" bindings. Maybe I will write some with the limited feature set XMPP needs in the future. Right now I use tlslite. > This is useful feedback, and I wasn't that aware of this. I talked at > FOSDEM about GnuTLS and did ask people to write perl bindings, since I > noticed there aren't even Perl bindings available. But I will ask > people to work on bindings for more languages. Please do. This would be very helpful. Dirk -- Theorem: a cat has nine tails. Proof: No cat has eight tails. A cat has one tail more than no cat. Therefore, a cat has nine tails. From dmeyer at tzi.de Fri Mar 6 12:01:37 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Fri, 06 Mar 2009 19:01:37 +0100 Subject: [Security] XTLS and DTLS-SRTP In-Reply-To: <6147.1236194052.073456@invsysm1> (Dave Cridland's message of "Wed\, 04 Mar 2009 19\:14\:12 +0000") References: <49AC57B6.8050109@stpeter.im> <87ab83wo5b.fsf@phex.sachmittel.de> <87eixdvd5o.fsf@phex.sachmittel.de> <6147.1236194052.073456@invsysm1> Message-ID: <874oy6cyym.fsf@phex.sachmittel.de> Dave Cridland wrote: > TLS has one defined, and we also have SASL, which we can't use for > much the same reasons, annoyingly. It's not too bad, though, we do > always have a signalling layer available, at least. > > So, you're thinking of something like: [...] Something similar. I;m not a security expect and found a nice solution doing a 5 way handshake. Not perfect, I know. But I would prefer something people know what they are doing designed. :) Dirk -- May your life be like toilet paper - long and useful. From dmeyer at tzi.de Fri Mar 6 12:09:45 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Fri, 06 Mar 2009 19:09:45 +0100 Subject: [Security] TLS Libraries In-Reply-To: <1289.1236351240.976798@peirce.dave.cridland.net> (Dave Cridland's message of "Fri\, 06 Mar 2009 14\:54\:00 +0000") References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> <1289.1236344668.417345@peirce.dave.cridland.net> <1289.1236350369.545250@peirce.dave.cridland.net> <1289.1236351240.976798@peirce.dave.cridland.net> Message-ID: <87y6vibk0m.fsf@phex.sachmittel.de> Dave Cridland wrote: > On Fri Mar 6 14:42:50 2009, Eric Rescorla wrote: >> You MITM the initial connection, then wait for one side to offer his >> proof. You then simulate a failure, crack the password, and move >> on. Note that if the password is short enough, you can crack it in >> real time and move on. > > Right, I see. > > Surely if I'm talking to Peter, and arrange a shared secret, and then > I find Peter rejects it, I'm going to tell him pretty quickly? I > accept it's possible to circumvent, and there'll be issues with > hardware doing this, though. You won;t see a rejection if the MITM in the TLS connection(s) is the same MITM that can change Jingle stanzas. So the server can do bad things. And the idea behind e2e (at least in my scenario) is that you don't trust the server. > This is certainly going to be harder to deal with - the 4-digit pins > are really related to hardware and other such dumb devices. I'd guess > that with SRP, the timescales are simply going to be a bit longer, > though? I talked to Thomas Wu, the author of SRP, and he confirms that SRP is secure even for short pins. In the ServerKeyExchange message, the server "commits" its knowledge of the password verifier, while the client does so in its Finished message. The server's Finished message confirms to the client that the server really knows the premaster secret and by extension, the password verifier. This is why the ordering of the Finshed messages is also important in the SRP ciphersuites. This means that the server must know the password in the second phase of the handshake, but sends only a hash of the password and a random value. No way for the client to guess it. The client sends the Finished message which is encrypted with the premaster key which is based on the password. The client only has one shot to get the password right. After that, the server proves that it has the password in its Finished message. No way to guess it based on the client's message because it has to match the information it send in its first message. I hope I got this wrong. This is how I understood it after reading TLS-SRP, SRP, and talked to Thomas. So for TLS-SRP both clients must know the password and have no way of getting it with brute force. They only have one change and if the passowrd does not match, TLS setup will fail. And a client should not allow 10000 attempts to open the TLS connection. Dirk -- In which level of metalanguage are you now speaking? From dmeyer at tzi.de Fri Mar 6 12:12:08 2009 From: dmeyer at tzi.de (Dirk Meyer) Date: Fri, 06 Mar 2009 19:12:08 +0100 Subject: [Security] TLS Libraries In-Reply-To: <49B120E2.5090007@stpeter.im> (Peter Saint-Andre's message of "Fri\, 06 Mar 2009 06\:10\:58 -0700") References: <49AC57B6.8050109@stpeter.im> <877i35q6b0.fsf@mocca.josefsson.org> <87wsb4t715.fsf_-_@phex.sachmittel.de> <200903050743.13342.justin@affinix.com> <871vtbbr3y.fsf@phex.sachmittel.de> <1289.1236344668.417345@peirce.dave.cridland.net> <49B120E2.5090007@stpeter.im> Message-ID: <87sklqbjwn.fsf@phex.sachmittel.de> Peter Saint-Andre wrote: > On 3/6/09 6:04 AM, Dave Cridland wrote: >> On Fri Mar 6 03:33:53 2009, Eric Rescorla wrote: >> >>> Obviously, you could do something SRP-oid at the app layer, but we really >>> should decide if dictionary attack resistance is an important element. >> >> I don't think it is - we're not talking in terms of a long-term >> shared-secret, we're talking about an ephemeral secret shared (say) over >> the phone, used purely to verify a channel, and, by that, optionally the >> peer's X.509 cert. > > Correct. AFAIK we're making the following assumptions: > > 1. Everyone has X.509 certs. > > 2. Some/most X.509 certs are self-signed, not issued by trusted CAs. Correct > 3. For the first communication session, the parties need to verify each > other's certs. They have to do it for every communication setup, but the first one is the problem if the certificates have no real certificate chain of signatures. > 4. If the certs are self-signed, that could be done by checking the > fingerprints via some other/trusted channel (PGP-encrypted email or > whatever), but very few people will do that. We don't want folks to take > the leap of faith, so we need an ephemeral password-based method. Yes. Comparing fingerprints sucks. A simple password is ok. Compare this to Bluetooth. > But, yes, we need to define the threat model. Dirk and I will work that > into the next version of our proposal. I have something written down in my thesis. Peter and I will figure out what we need to add to the draft. Dirk -- Hey! It compiles! Ship it! From stpeter at stpeter.im Sun Mar 8 23:56:36 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Sun, 08 Mar 2009 22:56:36 -0600 Subject: [Security] [Fwd: I-D Action:draft-meyer-xmpp-e2e-encryption-01.txt] Message-ID: <49B4A184.5080505@stpeter.im> FYI. -------- Original Message -------- Subject: I-D Action:draft-meyer-xmpp-e2e-encryption-01.txt Date: Sun, 8 Mar 2009 20:30:02 -0700 (PDT) From: Internet-Drafts at ietf.org Reply-To: internet-drafts at ietf.org To: i-d-announce at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extensible Messaging and Presence Protocol (XMPP) End-to-End Encryption Using Transport Layer Security ("XTLS") Author(s) : D. Meyer, P. Saint-Andre Filename : draft-meyer-xmpp-e2e-encryption-01.txt Pages : 27 Date : 2009-03-08 This document specifies "XTLS", a protocol for end-to-end encryption of Extensible Messaging and Presence Protocol (XMPP) traffic via an application-level usage of Transport Layer Security (TLS). XTLS treats the end-to-end exchange of XML stanzas as a virtual transport and uses TLS to secure that transport, thus enabling XMPP entities to communicate in a way that is designed to prevent eavesdropping, tampering, and forgery of XML stanzas. The protocol can be used for secure end-to-end messaging as well as any others application such as file transfer. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-meyer-xmpp-e2e-encryption-01.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090308/c3ba0ced/attachment.bin From stpeter at stpeter.im Sun Mar 8 23:57:05 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Sun, 08 Mar 2009 22:57:05 -0600 Subject: [Security] [Fwd: I-D Action:draft-meyer-xmpp-sasl-cert-management-01.txt] Message-ID: <49B4A1A1.1060604@stpeter.im> FYI. -------- Original Message -------- Subject: I-D Action:draft-meyer-xmpp-sasl-cert-management-01.txt Date: Sun, 8 Mar 2009 20:30:02 -0700 (PDT) From: Internet-Drafts at ietf.org Reply-To: internet-drafts at ietf.org To: i-d-announce at ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Management and Use of Client Certificates for the Extensible Messaging and Presence Protocol (XMPP) Author(s) : D. Meyer, P. Saint-Andre Filename : draft-meyer-xmpp-sasl-cert-management-01.txt Pages : 15 Date : 2009-03-08 This document defines methods for managing and using client certificates in the Extensible Messaging and Presence Protocol (XMPP). These methods, which make use of the EXTERNAL mechanism of the Simple Authentication and Security Layer (SASL) protocol, enable an XMPP client to log in to an XMPP server without providing a password. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-meyer-xmpp-sasl-cert-management-01.txt -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090308/ab05ac55/attachment.bin From stpeter at stpeter.im Fri Mar 27 13:56:27 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 27 Mar 2009 12:56:27 -0600 Subject: [Security] XMPP encryption summary from IETF 74 Message-ID: <49CD215B.8040109@stpeter.im> At IETF 74 earlier this week, I discussed end-to-end encryption with a number of people. Most of these discussions happened outside the BOF (that's how IETF meetings go). Several topics kept popping up, so I'll try to summarize them here... 1. Why Not Use OTR? Many IETFers use OTR to encrypt their IM traffic, so they wondered why we don't just use OTR. The last time I looked, I think there was only one library for OTR, so that might be a problem (also it is not fully XMPP-friendly because it was designed for cross-protocol IM only, not encryption of complete stanzas etc.). But I admit that I haven't looked at OTR in quite some time, so I'll try to review it again soon: http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html 2. Offline vs. Online Some folks didn't like the idea of XTLS because it is stream-based, not message-based. In particular, Pete Resnick [cc'd here because he's not on the list] noted that XTLS can't handle offline messages and so doesn't address all the use cases (as he put it, it seems silly to have one technology for encrypted communication when the other party is online and a different technology for encrypted communication when the other party is offline). Note that this objection applies only to end-to-end chat, not things like secure file transfer, since they go out of band. 3. Streaming Handshake, then Object Encryption? One possible approach we discussed was to use a TLS (or TLS-like) handshake to bootstrap trust or exchange keys, then to use object encryption after that for XMPP-native encryption. The use of TLS would then be restricted to Jingle (i.e., "this transport must be secured via TLS or DTLS before exchanging application data over the channel"). 4. Modifying RFC 3923? If we define an object encryption approach, it might be possible to modify RFC 3923 or define a 3923-like approach that removes the dependency on CPIM [RFC 3860] for messages and PIDF [RFC 3863] for presence, because that's one of the sticking points for implementation. It's also possible that we'd remove the dependency on MIME (no clients natively support MIME for XMPP traffic) and even X.509 (use bare keys, not certs). 5. JavaScript Clients More and more XMPP clients are being written in JavaScript. But there is no SSL/TLS stack for JavaScript. Furthermore, the dependency on X.509 is problematic because there is no ASN.1 support in JavaScript, either. (I also note that there is no OTR library for JavaScript.) If we can define something significantly simpler than XTLS or RFC 3923 or OTR, we would make it possible for JavaScript clients to play in this space. These considerations might lead us to favor something like (1) bare keys instead of self-signed X.509 certs [your key could in turn be signed by your X.509 cert or OpenPGP key if you have one], (2) TLS-like handshake instead of full TLS, (3) basic CMS [RFC 3852] instead of S/MIME, etc. There's a lot to talk about here, but I at least wanted to get some of the issues out in the open. If you participated in these discussions at IETF 74, feel free to amplify or correct this report. Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090327/7b40e2fd/attachment.bin From js-xmpp-security at webkeks.org Fri Mar 27 14:15:22 2009 From: js-xmpp-security at webkeks.org (Jonathan Schleifer) Date: Fri, 27 Mar 2009 20:15:22 +0100 Subject: [Security] XMPP encryption summary from IETF 74 In-Reply-To: <49CD215B.8040109@stpeter.im> References: <49CD215B.8040109@stpeter.im> Message-ID: <4C31FFDC-BBB0-4920-B690-CAAF65AF781D@webkeks.org> Am 27.03.2009 um 19:56 schrieb Peter Saint-Andre: > 2. Offline vs. Online > > Some folks didn't like the idea of XTLS because it is stream-based, > not > message-based. In particular, Pete Resnick [cc'd here because he's not > on the list] noted that XTLS can't handle offline messages and so > doesn't address all the use cases (as he put it, it seems silly to > have > one technology for encrypted communication when the other party is > online and a different technology for encrypted communication when the > other party is offline). Note that this objection applies only to > end-to-end chat, not things like secure file transfer, since they go > out > of band. Wasn't this possible using ESessions? ESessions were message based as well. > 5. JavaScript Clients > > More and more XMPP clients are being written in JavaScript. But > there is > no SSL/TLS stack for JavaScript. Furthermore, the dependency on X. > 509 is > problematic because there is no ASN.1 support in JavaScript, > either. (I > also note that there is no OTR library for JavaScript.) If we can > define > something significantly simpler than XTLS or RFC 3923 or OTR, we would > make it possible for JavaScript clients to play in this space. These > considerations might lead us to favor something like (1) bare keys > instead of self-signed X.509 certs [your key could in turn be signed > by > your X.509 cert or OpenPGP key if you have one], (2) TLS-like > handshake > instead of full TLS, (3) basic CMS [RFC 3852] instead of S/MIME, etc. Shouldn't this be possible with ESessions? Anyway, I'm fine with either, be it ESessions or XTLS. But we need to get it done. And we need to do that ASASP! In fact, it already should be done and in use! We _NEED_ end-to-end-encryption, no matter which one! -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 801 bytes Desc: Signierter Teil der Nachricht Url : http://mail.jabber.org/pipermail/security/attachments/20090327/066bb59e/attachment.pgp From justin at affinix.com Fri Mar 27 15:32:35 2009 From: justin at affinix.com (Justin Karneges) Date: Fri, 27 Mar 2009 13:32:35 -0700 Subject: [Security] XMPP encryption summary from IETF 74 In-Reply-To: <49CD215B.8040109@stpeter.im> References: <49CD215B.8040109@stpeter.im> Message-ID: <200903271332.35549.justin@affinix.com> On Friday 27 March 2009 11:56:27 Peter Saint-Andre wrote: > 1. Why Not Use OTR? > > Many IETFers use OTR to encrypt their IM traffic, so they wondered why > we don't just use OTR. The last time I looked, I think there was only > one library for OTR, so that might be a problem (also it is not fully > XMPP-friendly because it was designed for cross-protocol IM only, not > encryption of complete stanzas etc.). But I admit that I haven't looked > at OTR in quite some time, so I'll try to review it again soon: > > http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html Funny, I'd have thought OTR wouldn't be IETF-friendly. The same critiques that apply to Esessions apply to OTR. > 2. Offline vs. Online > > Some folks didn't like the idea of XTLS because it is stream-based, not > message-based. In particular, Pete Resnick [cc'd here because he's not > on the list] noted that XTLS can't handle offline messages and so > doesn't address all the use cases (as he put it, it seems silly to have > one technology for encrypted communication when the other party is > online and a different technology for encrypted communication when the > other party is offline). Note that this objection applies only to > end-to-end chat, not things like secure file transfer, since they go out > of band. [I don't see Pete CC'd?] I'd like offline message encryption also, but then replay protection and forward secrecy may become impractical. The options seem to be: 1) Don't have offline encryption. 2) Have offline encryption with lesser security. 3) Reduce security of online encryption so that online and offline are equivalent. I pick #2. Yeah, maybe it's goofy to use different approaches for online and offline, but unless you pick #3, there's going to be different security levels anyway. > 3. Streaming Handshake, then Object Encryption? > > One possible approach we discussed was to use a TLS (or TLS-like) > handshake to bootstrap trust or exchange keys, then to use object > encryption after that for XMPP-native encryption. The use of TLS would > then be restricted to Jingle (i.e., "this transport must be secured via > TLS or DTLS before exchanging application data over the channel"). Object encryption is nice, but probably not at the cost of being unable to use TLS as-is. We can have object encryption for offline messages I suppose, since we probably wouldn't use TLS for that. > 4. Modifying RFC 3923? > > If we define an object encryption approach, it might be possible to > modify RFC 3923 or define a 3923-like approach that removes the > dependency on CPIM [RFC 3860] for messages and PIDF [RFC 3863] for > presence, because that's one of the sticking points for implementation. > It's also possible that we'd remove the dependency on MIME (no clients > natively support MIME for XMPP traffic) and even X.509 (use bare keys, > not certs). I agree we don't need CPIM/PIDF or MIME. But CMS is the coolest thing ever. That said, I think the main reasons RFC 3923 is not implemented in clients are: 1) XSF simultaneously promoting ESessions/XTLS with better security (due to being stream-based), which is super confusing to developers and it makes it seem like the XEPs supercede the RFC. 2) Simple lack of time or interest in end-to-end encryption in general (nobody expects the dominant clients to implement any of this e2e stuff, right?). I guess if we could use TLS to bootstrap a session of CMS object encryptions that would be sweet. But let's be serious here, the more we deviate from the norm, the harder it becomes to have our proposal taken seriously and be implemented. > 5. JavaScript Clients I know the world is all web based now, but I draw the line here for e2e encryption. Maybe somebody can explain to me again how e2e encryption at the client side is all that useful when the client code itself is downloaded on-demand from the server you'll be sending IMs through anyway. May as well have the server do the e2e work. -Justin From js-xmpp-security at webkeks.org Fri Mar 27 15:36:13 2009 From: js-xmpp-security at webkeks.org (Jonathan Schleifer) Date: Fri, 27 Mar 2009 21:36:13 +0100 Subject: [Security] XMPP encryption summary from IETF 74 In-Reply-To: <200903271332.35549.justin@affinix.com> References: <49CD215B.8040109@stpeter.im> <200903271332.35549.justin@affinix.com> Message-ID: <20090327213613.58a7581a@webkeks.org> Justin Karneges wrote: > I know the world is all web based now, but I draw the line here for > e2e encryption. Maybe somebody can explain to me again how e2e > encryption at the client side is all that useful when the client code > itself is downloaded on-demand from the server you'll be sending IMs > through anyway. May as well have the server do the e2e work. A possible use case would be: You trust your server and want to communicate with someone else on another server which you don't trust. -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available Url : http://mail.jabber.org/pipermail/security/attachments/20090327/0d84d2a5/attachment.pgp From whateley at gmail.com Fri Mar 27 16:06:25 2009 From: whateley at gmail.com (Brendan Taylor) Date: Fri, 27 Mar 2009 15:06:25 -0600 Subject: [Security] XMPP encryption summary from IETF 74 In-Reply-To: <49CD215B.8040109@stpeter.im> References: <49CD215B.8040109@stpeter.im> Message-ID: <20090327210625.GB6300@nyarlathotep> On Fri, Mar 27, 2009 at 12:56:27PM -0600, Peter Saint-Andre wrote: > 1. Why Not Use OTR? > > Many IETFers use OTR to encrypt their IM traffic, so they wondered why > we don't just use OTR. The last time I looked, I think there was only > one library for OTR, so that might be a problem (also it is not fully > XMPP-friendly because it was designed for cross-protocol IM only, not > encryption of complete stanzas etc.). But I admit that I haven't looked > at OTR in quite some time, so I'll try to review it again soon: > > http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html OTR only encrypts message bodies. We could make a similar spec that uses the same message flow, algorithms, etc., but has a more XMPP-friendly message structure. It would probably be a lot simpler than OTR itself, since we don't have to do things like signal support with whitespace (ewwww.) It wouldn't be compatible with OTR, though. I doubt the official OTR library (as it exists now) would be able to handle it, and sending XOTR-encrypted messages through gateways wouldn't work. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://mail.jabber.org/pipermail/security/attachments/20090327/66b20b97/attachment-0001.pgp From stpeter at stpeter.im Fri Mar 27 16:56:53 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 27 Mar 2009 15:56:53 -0600 Subject: [Security] XMPP encryption summary from IETF 74 In-Reply-To: <4C31FFDC-BBB0-4920-B690-CAAF65AF781D@webkeks.org> References: <49CD215B.8040109@stpeter.im> <4C31FFDC-BBB0-4920-B690-CAAF65AF781D@webkeks.org> Message-ID: <49CD4BA5.6080704@stpeter.im> On 3/27/09 1:15 PM, Jonathan Schleifer wrote: > Am 27.03.2009 um 19:56 schrieb Peter Saint-Andre: > >> 2. Offline vs. Online >> >> Some folks didn't like the idea of XTLS because it is stream-based, not >> message-based. In particular, Pete Resnick [cc'd here because he's not >> on the list] noted that XTLS can't handle offline messages and so >> doesn't address all the use cases (as he put it, it seems silly to have >> one technology for encrypted communication when the other party is >> online and a different technology for encrypted communication when the >> other party is offline). Note that this objection applies only to >> end-to-end chat, not things like secure file transfer, since they go out >> of band. > > Wasn't this possible using ESessions? ESessions were message based as well. I don't think it was. At least, Ian always told me that the extension of ESessions to offline messages was quite experimental (or, if you like, even more experimental than ESessions itself). You can find more here: http://xmpp.org/extensions/xep-0187.html It's been a while since I read all the ESessions specs... >> 5. JavaScript Clients >> >> More and more XMPP clients are being written in JavaScript. But there is >> no SSL/TLS stack for JavaScript. Furthermore, the dependency on X.509 is >> problematic because there is no ASN.1 support in JavaScript, either. (I >> also note that there is no OTR library for JavaScript.) If we can define >> something significantly simpler than XTLS or RFC 3923 or OTR, we would >> make it possible for JavaScript clients to play in this space. These >> considerations might lead us to favor something like (1) bare keys >> instead of self-signed X.509 certs [your key could in turn be signed by >> your X.509 cert or OpenPGP key if you have one], (2) TLS-like handshake >> instead of full TLS, (3) basic CMS [RFC 3852] instead of S/MIME, etc. > > Shouldn't this be possible with ESessions? Everything is possible with ESessions, no? > Anyway, I'm fine with either, be it ESessions or XTLS. But we need to > get it done. And we need to do that ASASP! In fact, it already should be > done and in use! We _NEED_ end-to-end-encryption, no matter which one! Agreed. That's why it is on the proposed charter for the XMPP WG. Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090327/1a43aea7/attachment.bin From js-xmpp-security at webkeks.org Fri Mar 27 17:02:56 2009 From: js-xmpp-security at webkeks.org (Jonathan Schleifer) Date: Fri, 27 Mar 2009 23:02:56 +0100 Subject: [Security] XMPP encryption summary from IETF 74 In-Reply-To: <49CD4BA5.6080704@stpeter.im> References: <49CD215B.8040109@stpeter.im> <4C31FFDC-BBB0-4920-B690-CAAF65AF781D@webkeks.org> <49CD4BA5.6080704@stpeter.im> Message-ID: Am 27.03.2009 um 22:56 schrieb Peter Saint-Andre: >> Shouldn't this be possible with ESessions? > > Everything is possible with ESessions, no? Nope. We can't use it for anything besides messages. But implementing it in JS should work. So we have to decide what's more important here ;). -- Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 801 bytes Desc: Signierter Teil der Nachricht Url : http://mail.jabber.org/pipermail/security/attachments/20090327/635a87ea/attachment.pgp From stpeter at stpeter.im Fri Mar 27 17:10:41 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 27 Mar 2009 16:10:41 -0600 Subject: [Security] XMPP encryption summary from IETF 74 In-Reply-To: <200903271332.35549.justin@affinix.com> References: <49CD215B.8040109@stpeter.im> <200903271332.35549.justin@affinix.com> Message-ID: <49CD4EE1.1090202@stpeter.im> On 3/27/09 2:32 PM, Justin Karneges wrote: > On Friday 27 March 2009 11:56:27 Peter Saint-Andre wrote: >> 1. Why Not Use OTR? >> >> Many IETFers use OTR to encrypt their IM traffic, so they wondered why >> we don't just use OTR. The last time I looked, I think there was only >> one library for OTR, so that might be a problem (also it is not fully >> XMPP-friendly because it was designed for cross-protocol IM only, not >> encryption of complete stanzas etc.). But I admit that I haven't looked >> at OTR in quite some time, so I'll try to review it again soon: >> >> http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html > > Funny, I'd have thought OTR wouldn't be IETF-friendly. The same critiques > that apply to Esessions apply to OTR. The IETF is not a monolithic entity. The topic of OTR came up in my conversations with individuals who attended the IETF meeting. That doesn't mean that a specification for OTR (or OTR-NG or whatever) would be accepted by the IESG for advancement to Proposed Standard. >> 2. Offline vs. Online >> >> Some folks didn't like the idea of XTLS because it is stream-based, not >> message-based. In particular, Pete Resnick [cc'd here because he's not >> on the list] noted that XTLS can't handle offline messages and so >> doesn't address all the use cases (as he put it, it seems silly to have >> one technology for encrypted communication when the other party is >> online and a different technology for encrypted communication when the >> other party is offline). Note that this objection applies only to >> end-to-end chat, not things like secure file transfer, since they go out >> of band. > > [I don't see Pete CC'd?] I cc'd him on my original message and I've done so on this message. > I'd like offline message encryption also, but then replay protection and > forward secrecy may become impractical. The options seem to be: > > 1) Don't have offline encryption. > 2) Have offline encryption with lesser security. > 3) Reduce security of online encryption so that online and offline are > equivalent. > > I pick #2. > > Yeah, maybe it's goofy to use different approaches for online and offline, but > unless you pick #3, there's going to be different security levels anyway. My proposed solution for offline messages is that if you know someone is offline, send this: Ping me when we're both online. That doesn't seem to be very popular. But, hey, that's what buddy pounce is for, no? Personally I would be happy with your option #2. >> 3. Streaming Handshake, then Object Encryption? >> >> One possible approach we discussed was to use a TLS (or TLS-like) >> handshake to bootstrap trust or exchange keys, then to use object >> encryption after that for XMPP-native encryption. The use of TLS would >> then be restricted to Jingle (i.e., "this transport must be secured via >> TLS or DTLS before exchanging application data over the channel"). > > Object encryption is nice, but probably not at the cost of being unable to use > TLS as-is. > > We can have object encryption for offline messages I suppose, since we > probably wouldn't use TLS for that. Right. So we're back to the tradeoffs you enumerate above. >> 4. Modifying RFC 3923? >> >> If we define an object encryption approach, it might be possible to >> modify RFC 3923 or define a 3923-like approach that removes the >> dependency on CPIM [RFC 3860] for messages and PIDF [RFC 3863] for >> presence, because that's one of the sticking points for implementation. >> It's also possible that we'd remove the dependency on MIME (no clients >> natively support MIME for XMPP traffic) and even X.509 (use bare keys, >> not certs). > > I agree we don't need CPIM/PIDF or MIME. But CMS is the coolest thing ever. > > That said, I think the main reasons RFC 3923 is not implemented in clients > are: > 1) XSF simultaneously promoting ESessions/XTLS with better security (due to > being stream-based), which is super confusing to developers and it makes it > seem like the XEPs supercede the RFC. I don't think that's quite right. All the developers hated RFC 3923 from the beginning because it was totally un-Jabber-ish (you mean I need to code up a CPIM parser, a PIDF parser, and a MIME parser?!?). > 2) Simple lack of time or interest in end-to-end encryption in general > (nobody expects the dominant clients to implement any of this e2e stuff, > right?). I do think there's some of this. > I guess if we could use TLS to bootstrap a session of CMS object encryptions > that would be sweet. But let's be serious here, the more we deviate from the > norm, the harder it becomes to have our proposal taken seriously and be > implemented. Agreed. I think that XTLS is the closest we've come to something that is mostly plug-and-play for developers, because they can use their existing TLS implementation. >> 5. JavaScript Clients > > I know the world is all web based now, but I draw the line here for e2e > encryption. Maybe somebody can explain to me again how e2e encryption at the > client side is all that useful when the client code itself is downloaded > on-demand from the server you'll be sending IMs through anyway. May as well > have the server do the e2e work. That's an interesting perspective. I don't think that a JavaScript client necessarily is downloaded from the same server where you connect for XMPP communications, but probably that will be the case. I suppose that you could run some kind of comparison of the downloaded JavaScript against a canonical version (does anyone do checksums for JavaScript code?), but as far as I know that kind of thing is not very common. Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090327/0ce1b17a/attachment-0001.bin From stpeter at stpeter.im Fri Mar 27 17:20:53 2009 From: stpeter at stpeter.im (Peter Saint-Andre) Date: Fri, 27 Mar 2009 16:20:53 -0600 Subject: [Security] XMPP encryption summary from IETF 74 In-Reply-To: <20090327210625.GB6300@nyarlathotep> References: <49CD215B.8040109@stpeter.im> <20090327210625.GB6300@nyarlathotep> Message-ID: <49CD5145.7030906@stpeter.im> On 3/27/09 3:06 PM, Brendan Taylor wrote: > On Fri, Mar 27, 2009 at 12:56:27PM -0600, Peter Saint-Andre wrote: >> 1. Why Not Use OTR? >> >> Many IETFers use OTR to encrypt their IM traffic, so they wondered why >> we don't just use OTR. The last time I looked, I think there was only >> one library for OTR, so that might be a problem (also it is not fully >> XMPP-friendly because it was designed for cross-protocol IM only, not >> encryption of complete stanzas etc.). But I admit that I haven't looked >> at OTR in quite some time, so I'll try to review it again soon: >> >> http://www.cypherpunks.ca/otr/Protocol-v2-3.1.0.html > > OTR only encrypts message bodies. We could make a similar spec that uses > the same message flow, algorithms, etc., but has a more XMPP-friendly > message structure. It would probably be a lot simpler than OTR itself, > since we don't have to do things like signal support with whitespace > (ewwww.) > > It wouldn't be compatible with OTR, though. I doubt the official OTR > library (as it exists now) would be able to handle it, and sending > XOTR-encrypted messages through gateways wouldn't work. Right. If we were to go down that route, we'd need to work with the OTR developers to make OTRv3, which would at the very least include a way to signal that the payload is (1) XMPP or (2) text. Peter -- Peter Saint-Andre https://stpeter.im/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6751 bytes Desc: S/MIME Cryptographic Signature Url : http://mail.jabber.org/pipermail/security/attachments/20090327/a3eece8e/attachment.bin From jonathan.dickinson at k2.com Mon Mar 30 09:48:50 2009 From: jonathan.dickinson at k2.com (Jonathan Dickinson) Date: Mon, 30 Mar 2009 16:48:50 +0200 Subject: [Security] XMPP encryption summary from IETF 74 In-Reply-To: <49CD5145.7030906@stpeter.im> References: <49CD215B.8040109@stpeter.im> <20090327210625.GB6300@nyarlathotep> <49CD5145.7030906@stpeter.im> Message-ID: > -----Original Message----- > From: security-bounces at xmpp.org [mailto:security-bounces at xmpp.org] On > Behalf Of Peter Saint-Andre > Sent: 28 March 2009 12:21 AM > To: XMPP Security > Cc: Pete Resnick > Subject: Re: [Security] XMPP encryption summary from IETF 74 > > On 3/27/09 3:06 PM, Brendan Taylor wrote: > > On Fri, Mar 27, 2009 at 12:56:27PM -0600, Peter Saint-Andre wrote: > >> 1. Why Not Use OTR? > >> > >> ... > > > > It wouldn't be compatible with OTR, though. I doubt the official OTR > > library (as it exists now) would be able to handle it, and sending > > XOTR-encrypted messages through gateways wouldn't work. > > Right. If we were to go down that route, we'd need to work with the OTR > developers to make OTRv3, which would at the very least include a way > to > signal that the payload is (1) XMPP or (2) text. Or indeed more transparent. Being able to have a local proxy to handle the XMPP data is a great idea, only: - The OTR guys didn't get the XMPP end of it right (more in the rant). - Having a binding for each and every protocol is just plain pointless. - You will never support them *all*. - Whitespace signalling is just plain nasty, and could be lost between XMPP servers. - Only necessary for closed-gardens (which people should forget about in any case). - Again, it can break XMPP. Given: - It would probably be able to traverse a XMPP-MSN gateway, which is way cool. - Any XMPP client is theoretically supported. They need to go the route of SASL where they define a protocol that you embed in your protocol in whichever way you deem necessary. They are actually in a good position to define an e2e encryption negotiation protocol (like SASL) for which the OTRv3 is a 'mechanism'. If they are really serious about it, they should approach the IETF at some point to get some RFCs laid down (I doubt the current iteration would have made it as-is as a RFC) - however, I suspect that I am leaving the scope of this mailing list. In any case, if someone (PSA?) is going to liaise with them I suppose I should 'ave my say. By the way, why was the *no* communication with the XMPP community when they went about implementing the XMPP layer for OTR? Or XML community for that matter - because the signalling goes beyond not working well with XMPP. Surely you would expect them to ask whether something would work or not (it probably wouldn't on the server I am *still* writing). Certainly, if we gave the hand (or the finger) their current attempt would have made sense, but I suspect we would have been more accommodating than that. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/