 So, we will come now to Mr. Arsenault there who is going to have a talk about Javarro from a few of you, the secure communication. Yeah, please. Hey, Joris. So, we're here to talk about secure communications. My name's Peter Saint-Entrée, but I don't speak any French. St. Peter at Javarro.org is my e-mail, JAVR address, and everything I always say is in the public domain, so none of this got the right garbage. I'm here to talk about secure communications with Javarro. So, what's this Javarro stuff? This is a very brief overview. It's a set of open technologies for real-time messaging presence, multimedia negotiation, and more. It's really just an XML router. It was invented by Javarro Miller in 1998. It's powered by Streaming XML, which is kind of a bizarre concept, but, you know, Tim Bray didn't like it, but it works very well for us. So, we'd send Streaming XML over along with TCP connections, essentially. You just open TCP socket, and you incrementally parse XML, and you can do general. That's the short version. So, we have a client-server architecture which enables us to build a decentralized network for inter-domain messaging. It's basically like e-mail, but really fast with built-in presence. But it's not one open-source project. Javarro's different from something like a PAD-CE or Linux. Multiple code bases. There's open-source code. There's commercial code. There's shareware. There's freeware. There's all sorts of different kinds of code that we have, because we really focus on the protocol, not the code base. So, our core protocol has been standardized through the IECF. It's not a final standard, but we're working through a final standardization of that with the Internet Engineering Task Force. When we took it there, we didn't call it Javarro. We called it the extensible messaging and presence protocol, or XNTP, because you need a four-letter acronym for all good protocols. That's defined in RFCs 3920 and 3921. I wrote those, and I don't suggest that people write RFCs unless they have a death wish. It's been widely deployed. How many users do we have? Well, we really don't know, because it's a decentralized architecture. We don't keep track of who's downloading servers and how many people are using this stuff. We estimate there's about 50 million users. And that's, for instance, the messaging. There's a lot of other stuff that you can do with Javarro. It's because it's not just IAM. It's general XML grounding, essentially. So there are lots of applications beyond IAM. And we're continually defining extensions to the core protocol, but we don't do all those all in the ITF because we have limited bandwidth and it would take us too long. So we define those in something called the XNTP Standards Foundation, which until recently we called the Javarro Software Foundation, but we never did any software, so we decided to change the name and we're accurately described what we were doing. So that's great, right? We have 50 million users, big deal. But how secure is it? I forgot, 15 million people sending unsecured messages. It's not really a good thing. We're actually maybe harming the internet more than we're helping it. And we want to be good internet citizens. So what is security? Well, there's a lot of definitions. So I thought, let's visualize, what is a secure conversation in real life? Because these are the analogies that we can use to figure out what security is on the internet. Let's say you have a good friend over to visit your home. It's your house, right? You know each other, you trust each other. He's probably not wearing some recording device to figure out what, you know, take this home and then post it on the internet when he gets home. It's only the two of you, right? There's no people listening in. Maybe you've got someone out the window and you can close the window, right? Strangers can't enter your home. Like they can on the internet, you can intervene in these kinds of things. Your home isn't bugged, you hope. You know, maybe you check your room for bugs before you start to have your conversation. The conversation's not recording. You're not recording it. Your friend's not recording it. What you say is private and confidential, right? If you take a walk on the hiking mountains or you have someone over to your house, this is the assumption that you have, is that your conversation is private and confidential. Contrast this with the internet. The internet is a dangerous place. Don't use the internet. There are lots of potential attacks, right? We have men in the middle. We have unauthenticated users. We have address spoofing. We've got weak identity, road servers, denial of service, directory harvesting, buffer overflows in various code bases, spam, spams, bits, blogs. There's all these nasty things that can happen to you. It goes on and on. There's viruses, there's words, trojans, malware, phishing and farming. We have to come up with new terms for this stuff all the time because the internet is such a nasty place. You put a machine on the internet and you can see how long it takes to get attacked, right? There's information leaks, there's people logging things and you don't want them to log them, and so on. So how do we fight these threats in the Java community? Well, I have to first apologize, but Java is not a perfect technology. It was not originally built for high security. It was originally built by hackers who said, hey, let's get something working. You know, we don't like game. We don't like ICQ. Let's build something that's a real technology that we can develop ourselves and not be beholden to these large corporations. Typically, American corporations. I'm American, by the way, so. So we don't require GTG. We don't require X509. We don't require ubiquitous encryption. It's not silk. It's not hushmail. It's a very open technology. Maybe that's why we have 50 million users. How many people are using silk and hushmail in these kinds of technologies? It's not 50 million, I don't think. But privacy and security have always been very important in our community. And even though we haven't necessarily done a great job of that, we're at least trying to improve. So what have we done to help? Well, let's look at the Java architecture. Hey, this looks familiar. Clients and servers, right? Oops. It's a client-server architecture somewhere in the evening. So a client connects on a TCP connection. TCP socket is 5222. Or we have HTTP over SSL in these kinds of things. But the typical is a TCP connection over 5222. Which, if you don't want to do Java communications, you can close off that port and off you go. The client must authenticate. We don't have any of this authentication as optional like you'd have in SIP and stuff like that. Original technology, so it's plain text password. Obviously not a very good idea. But I still do it with the Telnet client that I use and by connecting the same subnet. I don't worry about it too much. Hash password, which is the other early technique that we had. Then we took things to the internet engineering passports and said, hey, we've got this great technology called SASL. Simple authentication and security layer. And it has all sorts of mechanisms. It's defined in RFC 4422. It used to be 2222. So there are many SASL mechanisms. You can do plain, which is okay if you've got the SSL and encrypted connection. Digest MD5. Some people like that, some people don't. There's varying philosophies on that. External, so if you're using X509 or IP SAC or something like that, you can use SASL external. Kerberos, there's a lot of like, guys at MIT who had a news gatherer. Dave Ries and Cooper Kerberos, some of the investment bands, these people, people. SASL anonymous, so you can have anonymous users maybe if you have a support, you know, a technical support to an application. And so on. There's a lot more. So all of our users are authenticated and the server asserts what the from address is. So you can't say, oh, I'm service at PayPal.com. It just doesn't work that way. If you aren't a server teller, it informs other people what your sender address is. So you can't just assert that you want to be a certain person on gatherer. So what do these gatherer IDs look like? Well, they're logical addresses. They look like email addresses. I always use the Shakespeare examples. Romeo at Montagueen.net, Juliet at Capulet.com, you know, Bard at Shakespeare.lit, these kinds of things. But they're not limited to U.S.S. characters. So unlike email, you can have Play-Doh at hellots.gr and you can have Thai addresses and Japanese addresses and these don't work. You can have them in the domain name too, but I don't want to get too confused. The possibilities are essentially good. And you see people with gatherer addresses like this, it's pretty cool. So we have a full year to go, but it's good and it's bad because now you can have some nice fishing attacks. For instance, my address is the same peer at gatherer. What's the, you know, does Aunt Tilly really know that this one uses Cherokee characters instead of ASCII characters? Probably not. So she said, oh, this looks like my friend St. Peter at gatherer.org, but it ain't. It's someone else. So the clients use pet names and things like this to try to get around some of the possible fishing attacks. We haven't seen these happen, but we need to be prepared. So these all get stored in your buddy list. Buddy list is a trademark term from AOL, so I don't typically use it. We call it a roster at gatherer. So the server storage is a roster, so that when you connect to various clients, it's all there for you. You don't have to store it when you're a local machine. And the server broadcasts your presence or your availability. So once you get on the line, you can say, hey, everyone that I care about, here I am, I'm on, I have network availability. And this is called presence, but the server only sends this to people who are authorized. There are some consumerist investing systems out there which will give your presence away to anyone, which is really not such a good idea. We don't do the things that way. The server also must not expose your IP address, not like something like IRC, where you can log into IRC, and everyone knows what your IP address is. It's really not such a nice thing, I think. Most of the traffic goes to the server. We can disappear and appear stuff. We actually have a server which knows that the one-line or tile people are going to use. But most traffic, typically in typical implementations and deployments, goes to the server. Traffic is pure XML, and you can validate even against the schemas that they want. Typically, people don't do that, but at the least they check for well-forming bits. This makes it difficult to inject binary objects, difficult to propagate malware. In part, what this helps us do is break the alliance between the virus writers and the spammers. There's actually this unholy alliance between the virus writers and the spammers, and they get along quite well because they're all trying to harm us in various different ways. We basically don't have what's called SPAM, which is SPAM over IM. You know, the SPIC, which is SPAM over Internet telephony. And we all know what's logs over, of course. SPAM or SPAM logs. We basically don't have SPAM. I'm not going to say that we don't have any. I've been using Java since 1999, and I don't think I've ever received any SPAM except when I was connected to ICQ over the various gateways that we have. But I'm not going to say that we don't have it. So why is that? Well, it's hard to scoop through the addresses. It's hard to send this inline binary stuff that, you know, so you can get image spam all the time now to get around the basic filters. We have a XHTML subset, which is kind of a safe subset of HTML that we can do form-added messages, but not send scripts and images and these kinds of things. The clients are very much encouraged to check with the user before accepting any file transfers. I'm not saying we're a new spam, but we have a lot of spam fighting tools that we've been working on that we should have ready in time before the spam has really discovered us. For instance, we can act through a challenge response to figure out something as bot versus a person, or before you register an account. And we're working on ways to report spam to your server, and your server is going to report to each other, and we can figure out if there are road servers on the internet. We may even work on reputation systems farther down the line. And the spammer is one thing they need to do is overcome rate learning. So we limit the amount of packets that we can send to the server, and this is the way most of the servers are written, to try to prevent road clients from connecting to legitimate servers. So if you really wanted to get serious about expanding the Java network, you'd either have to launch a road server, but you get discovered pretty quickly because we check all the from addresses, or you have to launch a distributed attack to get a lot of different bots connecting to various different servers and have enough of them that you can get under the rate limiting and send enough spam to really make it worth a while. It's not been possible as just part of another network. So if you've got email, it's might as well attack the email infrastructure first because Java infrastructure is just too much of a pain. And we don't really have any road servers yet, but if we do, we're going to have to figure out ways to tell each other that they exist. So server federations by which I mean inter-domain communication is optional. When I said we have 15 million users, those are not all users on the open internet. In fact, a lot of people use Java at universities or at companies, and they don't connect to the rest of the network, but just fine. They're using our technology the way they want to use it and we don't have any problem with that. So that server federation is optional because there are many private XMPD servers out there. The public servers federate on a different port, so if they want to do federation, they open up a separate port from the client communication with just five, two, six, nine. DNS lookups, so we do DNS lookups to determine IP addresses. Obviously DNS can be poisoned, so we'll talk about that as well. There's only one hop between servers, so unlike email where there's sort of the best effort delivering, oh, I get it part of the way, we only have one hop between the servers, which is that direct server-to-server connection. Server identities are validated. We have a couple ways to do that. The first way that we have the server dial back, which we instituted in 2000. So until October 2000, you could still spoof server domains on Java, and it was a bad thing, so we got rid of that, and we said we can't connect in the old way. This is ancient history for Java, by the way. We've been around since 1999, so. So we do reverse DNS lookups. If you tell me that you're postman.org, I say that's very nice. Thank you very much for saying that you're postman.org. Let me check into DNS and see who postman.org really is. I check to that IP address. I say, I have this connection over here. It says he's postman.org. Is that really true? There's keys that get passed back and forth, and then we can check whether this server really is postman.org, and if I get back from the authoritative server, then I tell this connection, oh, that's, you know, postman.org came out, and if I don't get back the right key, I say, sorry, I'm going to close this connection. So this effectively prevents servers from being back. And the receiving server, once that connection is open, now checks the sending domain on every packet, and so if the server was postman.org, and now it wants to say that it's PayPal. Java.org, which is neat over here, is going to say, no, I'm going to reject that packet, and I'll close that connection here. So basically, we have no one of these messages from people who are not who they say they are, because we validate all the identities on the network. Now obviously if you do DNS poisoning, you can invalidate this, because if you poison DNS, you can get the wrong results, right? So if we need something stronger, we use something called transport layer security, which is RFC 4346, which is the ITF upgrade SSL. So this enables us to do channel encryption, and if you use channel encryption with TLS and certificates, and you refer to the SSL external mechanism, you can really tell if someone is, well there's still maybe some problems, and some people just do a direct IP to IP connection for server to server if you really care about it. So this enables us to do strong authentication of other servers, but only if you're not using cell sign certificates, because if you're using cell sign, anyone can do a cell sign certificate, right? It's totally meaningless. The problem with this as usual gets back to money. These are dollars, maybe I should have used zeros here. So real X509 certificates are expensive. How many people here are going to go to VeriSign or Faw or something like that and buy a real certificate for their Java server? They're probably not, because we're just a bunch of hackers, we don't have this kind of money. So what we want is free digital certificates, right? Free is good, free is a free beer for X509 server admins. So what we've done is we've set up an intermediate certification authority for the Java network and that's at XMP.net So our root CA is Starcom, which is a CA based in Israel and then we set ourselves up as an intermediate certification authority through Starcom to offer free digital certificates to Java server admins. So if you have a Java server and you want a free certificate, you just come to us and we have free certificates. This really encourages people to do end-to-end channel encryption. So hopefully we'll work with other CA's in the future. I've done some work with CA cert and you can do the CA cert route as well because I work with those folks to get the XMP supporting there. So this basically makes channel encryption a no-brainer and we should by the end of the year, we're really trying to work out so that we have mostly ubiquitous channel encryption, both server server and client to server. So this really causes problems for Mallory. I don't know if you remember your security characters. Mallory is the man in the middle, right? So if I have my client in the server, I want to connect to my server, Mallory is now foiled. But it doesn't really help us with Isaac and Justin. Isaac is your ISP and Justin is the justice system. So your ISP could feel like we're listening to this traffic even though you have an encrypted connection between the client and the server, it's now unencrypted as clear text while it's inside that server application so that your Isaac could be listening into everything that you're saying because he's your ISP. And maybe Isaac is friends with Justin and Justin wants to know what's going on as well. So it doesn't really help to have ubiquitous channel encryption if, within the server applications, we have a clear text. So we need end-to-end encryption or what we call EDE. And we've had Mary's kept to this because we're not security gurus and even the security gurus have sometimes different advice about how we should be proceedings. The first way we did this was OpenPGP. We have a series of documents called ZEPS and this was ZEP 27. Exactly, we had this very early on in the Jarrett community to use OpenPGP to encrypt our packets that we send for full encryption end-to-end. This is great for deeps, right? How many people here use OpenPGP, GPG, something like that, right? See, we're all gone, right? We're a bunch of geeks. We use this stuff. But Ann Tilly does not use PGP and she never will, right? She's a very sweet lady that Ann Tilly, but she's just not very technically savvy. So then we said our second try we took our stuff to the IEPF and the IEPF said, oh, you don't want to use OpenPGP. You need to use S1. Now, S1 is great technology but there are more S1 implementations out there than there are S1 users. I mean, how many people are signing their email with S1? All right, there's three or four of us. Yeah, I do that, right? But it's great for geeks. And even the geeks here aren't using it, right? And it's great for summer toys because there are some companies that you can get a smart card or you have in the U.S. Army, they have these cat cards and you just slip it into a machine and all your credentials are there and they're using S5 online. But they have control over your user base so they can tell people that you need to use this card or else you can't get it on the network. But again, Ann Thilley does not use X509 and she never will. She probably more likely to use DPG. What about external encryption and digital signatures? Well, it may seem like a natural thing but there really has not been much developer interest in this. You've got the economic utilization, which is C14n. It's really no fun. And it doesn't provide what we call perfect forward secrecy. So if your keys get compromised someone can go back and read all your old documents, which we really don't think that's such a good thing. So then there's something called off-the-record communications. I know how many people use game or ADM and you have off-the-record communications. It's really cool. It's a great idea. It's opportunistic encryption, something like SSH. So you get that key once and then once you connect over SSH again, as long as the key is the same we figure it's okay. Now someone won't have to attack that first connection and then attack the future connections. But once you've accepted that key from your server on SSH, you're pretty much happy, right? So that provides perfect forward secrecy to our technology. But it encrypts only the message body. So if you say hi, it encrypts a hi, but it doesn't encrypt anything else. It's in the packet. We need to encrypt the entire packet. Why is that? Well, because we're more than I am. We're not just sending a couple of messages around. We're sending soap and we're sending forms that might have sensitive data in them for workflow applications. We might want to protect the IP addresses that we send in a multimedia negotiation because we don't want to expose IP addresses. So we have been working for a while on technology called encrypted sessions. It has a very large set of requirements which sounds like it would be even possible to meet, but OTR pretty much meets them and we kind of tweak how that works and follow some other technologies that work with a guy named Ian Patterson on this and a guy named Dave Smith who sort of started the ball rolling. So the packets are confidential, right? We don't want anyone to be able to read things in transit even Isaac adjustment. We need to know if the packets have been tampered with, so that's integrity. We need to know if the packet is replayed so if someone sends us the same packet again and they're trying to foil our encryption technology. The compromise of the keys does not reveal the past communications. That's perfect forward secrecy because we don't want to use BKI because people don't use BKI. BKI is not widely deployed enough and never will be for everyone to be using this technology. So we don't want it to be necessary, but they are maybe we can reuse it. The entities are authenticated to each other just like when your friend comes by your house. You know that it's your friend who's not faking it and he's got some next-large number soon, you know, he's the same person. Third parties can't identify who the identities are who are talking. This is a nice thing. We can re-trudiate these identities if we want. And we have robustness against attack. You have to sort of go through a lot of different things in order to attack the technology. If we find bugs in that technology we want to be able to upgrade it to new versions so we need some good versioning. And we want to print the full packets. And ideally it would be implementable by your typical developer and usable by your typical user. So it sounds impossible. Is it just a dream? Well, maybe it is but we're trying to figure it out. So how do we address all these today requirements? Well, we're trying to bootstrap from clear text encryption which is what Dippy Hellman does. So we're trying to do an in-band Dippy Hellman experience. This technology is actually more of an approachable Sigma which was published years ago and that's what gets used in IK which is the Internet Key Exchange of the IKF demo. So what we've done is we've taken all those insights and we're trying to work a way to do that over Java because we have a real-time communication system. We don't have to do object encryption but you never know when someone's going to pick up the email. We can encrypt essentially in real-time and use that fact that we have sessions to have a smarter encryption technology. So we have a bunch of Zeps that talk about this so 116 and 188, 200 and it's really become a major priority for us in 2007. And Hellman has decided to give us some support to do some work on this and we're very appreciative of their support and we'll be announcing that right now. So we're presuming a full security analysis to get these technologies reviewed by real security mafia people. They call themselves a security mafia. I know it's kind of scary but real security experts do a security analysis and code about these projects out there, libraries and client developers to try to get this code out there so that we can have a couple libraries maybe that people can just drop into their clients and then we can have end-end encryption. And we're going to be posting more about this at our blog. We don't do press releases anymore, we just blog. So we have a blog, a blog that acts as a feed-out word and we're hoping we're really soon to provide recommendations at the end of the year. So how are we doing on all these threats? You know I went through 20 threats out there but we're pretty much spin free at least I'm spin free and I have 1,500 people in my buddy list and I've never received any I figure I'm going to be a good spam you know people are going to get it when we meet. One of these days someone's going to launch a denial of service attack just against an EAP. It's hard to spoof the addresses we have this pure X and also it really discourages malware. The docs attacks they're possible but it's not easy and we're trying to make it as hard as we can. We have very widespread encryption in all the server implementations we're giving away certificates to try to use this stuff and we're working hard on end to end encryption. Jammer has been very widely deployed in a lot of high security environments. They don't like to talk about it because they don't like to talk about anything but basically all the Wall Street investment banks are using it. A lot of them use the Kerberos or they have X509 because they've got little smart cards that you have to use to get onto the system. A lot of US military applications that I don't know about and even if I did I couldn't tell you. My team's famous is that's the place where you hack into networks and stuff like that. They're using Kerberos as well I believe for their authentication on their jabber server. We've had a lot of public servers all the internet we probably have you know I would say 15,000 or more servers on our network and it's been out there since 99 obviously it's been growing. We've never had any major security reaches as far as I know through jabber reports. There's no people installing trojans on the via the jabber reports. They might do it over HP with PHP hacks and things like this. But it doesn't mean that we can be complacent. There's always more to do. We know that security is never any process. We are encouraging people to analyze our technologies and try to hack into our network if they can right because that's how we learn and if things break we'll fix them and if they don't break we kind of figure that hey maybe this is a good thing but we need to keep improving our technologies. We have security mailing list. I actually just reset this up this morning because we want to be able to have ways for people to just talk about security stuff. So we have security that's going to be out of work. And I say join the conversation and let's try to build more security. So thank you and I hope you have lots of questions for me. Security is a controversial issue. You have to question some of my assertions I said things but they may not be true. How can you believe me? Okay would there be a way to have encrypted server side logs? Yes there is in fact. So we have I didn't talk about it here because I forgot about it. So we have a technology for what we call message archiving so let's say you've got a web client right the web client isn't going to keep a lot of people like to keep their IM logs so you can go back and search through them and find out yeah last week I was talking to Trees and he mentioned something and they go back and find it. I don't personally log my IM because I don't it's not encrypted so I don't like to keep it there. I do encrypt my file system but you know how much do I really trust that. So we do have a method for doing that we have to find from archiving messages on the server side and then you use some key materials that you come up with to securely save those logs on the server so that even though you've logged the conversation only you have that information it's not implemented really yet we have a couple people working on implementing it there's some things that the clients need to do and some things that the servers need to do to make that happen but we have to find a way to do that it's a question of getting it implemented and deployed well what do we do as road servers? Well again we haven't had any so we haven't really worked out some of the techniques. We mean if we had so let's say we had road servers so yeah if we had road servers let's say we had Spimmer.com Spimmer.biz decided to attack our network some of the servers have dynamic whitelisting and blacklisting some of the server implementations so you can dynamically say I don't want to communicate with certain domain I don't know that all the servers implementations have that obviously you can block it before you get to the application layer and you can block it if I put tables or something like that if we had road servers we had a lot of road servers we really cared about this if we had one road server people would learn about it pretty quickly and try to block it yes so you could write your own entity server which kind of looked like it did all the right stuff for the protocol and then it didn't ask me things after that or it just sent a lot of packets we also have rate limiting a lot of the server implementations have great limiting for servers server implementations as well so if we started to be flooded by a certain server they would get rate limited they could send fewer packets and so they would have to stay within some boundaries typically of how much traffic they could really generate we haven't seen those yet but I'm sure we will once we have enough part of the problem with this investment team which is the main application for Dabber is that we have these communication silos MSN, Yahoo AOL, and ICQ so we don't have we don't have an open network like we do with email which is a bad thing because you can't talk to everyone you need for IAM clients but on the other hand it could even be seen as something of a good thing but we don't have the kind of open communications that we have with emails so it's not as much of a challenging target to try to attack I personally would prefer open communications over these communication silos but once we have get rid of the silos and this is the excuse that AOL always uses oh we want to open up we really do but we need to protect our users well maybe you do and maybe you don't but so I think that's one of the reasons that we don't have a lot of spam on IAM now they do spam on things like ICQ because there's consecutive numbers and so you can just hey I understand this number and I'm going to eat from that bite one and I'm going to spam the next number and I'm going to spam the next number it makes it very easy and I don't know how AOL does it for AOL is the message you're ever sending AOL the addresses and then start spamming them it's a little harder to do that in Jabber the only directory hardest attack I've heard of in Jabber was on a server where the email address was the same as the Jabber ID and so they attacked the we have these user directories they attacked the Jabber user directory just to get the email addresses and then they would spend spam by email because it was too much of a pain to send spam by Jabber but at least they could get those addresses the same this was actually there was a big jabber service in Cuba for some reason and this was one of the servers in Cuba yes how can people tell the difference between each other oh I'm sorry I was pointing to this person way in the back but I'll take your question first how many people didn't tell the difference between a Jabber address and an email address well we should be using URIs right I mean if I put a domain name on the side of the bus and it says what the hell is that do I do HTTP do I do FTP I need a protocol in front of something so yeah there's confusion about sometimes between Jabber addresses and email addresses because you should put on your business card Jabber ID is this and email ID is that now I happen to be one of the admins for the Jabber.org server and I'm also one of the mail postmaster and all that kind of stuff so what I will see is that people are trying to send spam to addresses at Jabber.org that are actually Jabber IDs because there's only like 5 people that have email addresses at Jabber.org everyone else just has Jabber IDs so I see all these people who have advertised that they have Jabber ID at Jabber.org on their website and the spammers are now going through and trying to harvest these and send spam either to or from these addresses that don't exist so it's really kind of sad for the spammers in fact I think that the Jabber IDs are different from the email IDs but the only categorical way to tell is to put the URI scheme in front of it and then you know what the entity really is and we have a URI scheme it's RFC 4622 so we have an S&P URI scheme but as a S&P colon St. Peter at Jabber.org you can tell that it's different from mail to a Jabber.org and that's what URI schemes do for us yes, if you just speak I'll repeat your question so the question is we set up this certification authority and someone who now comes and says oh I'm PayPal please give me a cert well, shortly because we do a lot of stuff to figure out whether you really are who you say you are what is that process one is that you request an account at XMPP.net which doesn't get you to be certification authority at all all that we do is we do some whom is look up so we verify that this person is associated with the domain this is a good question and so what happens is that a lot of people will say oh yeah I want to register an account at XMPP.net because I want to get a certificate and we see that they're not associated with this domain at all so then we say are you really associated with this domain and we do mind if we can contact the domain owners the registrants for this domain and then they say oh yeah please don't yeah that's okay I don't really need this account or they say yeah I really am the Jabber server admin but I don't have access to all the postmaster addresses and all that kind of thing so then we contact the real owners and say hey this person who is because you're going really part of that domain and if they say yes then we will let them have an account at XMPP.net but that just is the first step so in order to get to our certification authority you have to get from a certain URL when we do an HTTP post and all these kinds of things to go from there and then get to the internet to the certification authority website and then there's all sorts of other groups you have to jump through once you get to the certification authority website to prove that you really are associated with the domain and they do all sorts of checks of the IP addresses and the mail servers and that they send to one of the canonical addresses in the RFC 4122 and so on and so forth and you get this key and you got to come back with a certain amount of time and then you can really get your certificate and then if they find out that you really are who you say you are we'll just revoke your certificate and throw you out. So we do a lot of things to try to prevent people from trying to gain the system but I'm not going to claim that it's perfect because if you claim perfection with regard to security technology, someone will figure out a way around it but we're trying to do the right things that's the long story Yes Can we do the juggler technology nightfall for 100 years or I guess you're juggling it all or you're working Oh, yeah, yeah, for a person So you're talking about onion routing Okay, so there's a technology called TOR How many people have heard of TOR or onion routing? Oh cool, I use TOR TOR is cool So TOR is really cool and you can do Jabber over TOR I haven't set it up because I had trouble setting up the service the TOR services spending enough time to figure out how to set up TOR services but you can set up Jabber as a service under TOR and then you can use the TOR onion routing to hide what the path is the network and those kinds of things One of the problems is that if you've used TOR, you know that there's latency involved and people don't like latency when it comes to instant messaging they're just not very tolerant of it so even though we can do it I think there are some people who will because they're typing really fast and they want to get the communications right away So it can be done but I don't think that a lot of people will ever use it I've seen people with if things aren't going through right away but yes, it can be done I haven't tested it myself I should do that though because I like the concept of TOR especially if you're in a country and you're trying to be a journalist or doctors against borders and these kinds of people who are trying to work in Myanmar or some place like that you don't want people to know what the path is of your communication so how do we ensure that TLS will be used if it's available so we are able to as a server policy you can say that TLS is required so a server can not only offer TLS but require TLS we're not probably going to do that very soon because we're still waiting for more people to get certificates but I can see the day in maybe 12 months or 18 months where a lot of servers will just say you know I'm not going to accept TLS, you must have a certificate and that day will come but we're working towards that but all the servers and the underlying protocol have the way to require the use of transport-related security we don't really, we don't have a way right now to do kind of a trace route right so if I'm a client over here in Europe, France down over there I don't have a way right now to check the whole path and know that there's TLS but of course you have to trust all the entities in the middle to tell it to really so you're back to square one at that point because you have to trust that your Fosna.org is really giving the appropriate results for whether it's using TLS for the connection between you and the server and this connection so there's kind of problems there and if you're using some HTTP connector that's kind of a proxy in there to really check that full path there's a lot involved at that point you know there's a disease and anti-encryption I think yes there's no support required from the server we don't trust the servers people who want to do anti-encryption don't trust the servers and they're justified with trusting the servers because Isaac and Justin might be there in the middle and they might be trying to listen in so there's no server support required at all if you want to do certain forms of anti-encryption you probably want to have a way of storing your keys on the server your public key is not your private key but to store your public keys on the server so you might have to have some level of trust I suppose in your own server in the sense that it's not but if it's going to compromise your keys there you don't have to store them there that would be helpful for certain kinds of scenarios for offline messaging you can send a jarring and send a message on the server and then it gets delivered when the other person comes online but obviously if you're not going to do that with this anti-encryption technology because at least not right out of the box because that person is not going to be able to read the message so we have some fancy stuff that we do to have an offline mode for this as well yes so do I actually ever foresee problems of people governments let's say organizations saying you know we're not going to allow any traffic that is trying to use this anti-encryption technology well you know I'm not I foresee corporations, a lot of corporations they have legal requirements at least in the states or Sarbanes-Oxley and these kinds of reporting requirements so they need to actually store the messages that people in their corporations send for legal purposes and they won't be able to use this technology obviously but that's going to be a corporate policy well I don't know how they're going to enforce that I'm not sure they can try to do traffic analysis and if you send things in certain names bases in XML they will throw it out and just mess with things but is that possibly going to happen with me because we know who's involved and who cares about these things but we may care more about anti-encryption than they care or even pay attention to Java but I certainly see that for corporations