On Aug 25, 2013, at 5:36 PM, John Young <jya@pipeline.com> wrote:

Phil probably means the infrastructure of email is the vul not the crypto. Crypto alone is sterile, a boy in a bubble which requires life support which can be assaulted.

That's precisely what we mean. The crypto is the easy part. The hard part is the traffic analysis, of which the worst part is the Received headers. Everyone should look at their own headers -- especially people on this list and at least comprehend that your email geotracks you forever, as it's all in the Mailman archive. There are plenty of other leaks like Message-ID, Mime-Version, X-Mailer, the actual separators in MIME part breaks, and so on. It's absolutely correct that some combination of VPNs, Tor, remailers of whatever stripe, and so on can help with this, but we're all lazy and we don't do it all the time. What we're learning from Snowden is that they're doing traffic analysis -- analyzing movements, social graphs, and so on and so forth. The irony here is that this tells us that the crypto works. That's where I've been thinking for quite some time. Imagine that you're a SIGINT group trying to deal with the inevitability of crypto that works being deployed everywhere. What do you do? You just be patient and start filling in scatter plots of traffic analysis. The problem isn't the crypto, it's SMTP. Jon

On Aug 30, 2013, at 8:43 PM, grarpamp <grarpamp@gmail.com> wrote:

Are we sure? This seems to tell us they are doing traffic analysis and so forth. It doesn't seem to say much about cryptanalytic capabilities. For all we know they could have all the crypto in the bag but need analysis to identify talkers due to people being exceedingly careful about the message content.

I consider delivering a zero-day to be a form of cryptanalysis. I believe that they do, too. I've been harping on that for some time.

"Blue hen rides over the book on the left side when the sun is low. Do you copy?"

Now if someone leaked all the secret crypto capabilities docs out in public, or someone else got in trouble solely from what they properly encrypted, then we'd know whether or not the crypto works.

I recognize that I have a tendency to be glib in one sentence and then rigorous in another and that's a character flaw. It's glib to say both "the crypto works" and "zero days are cryptanalysis" in many respects. When I say, "the crypto works" I mean the basic structures. We know how to build block ciphers. We figured out hash functions a few years ago. We understand integer-based public-key cryptography well enough that it gives us the creeps. We kinda sorta understand ECC, but not as well as we think we do. I think our understanding of ECC is like our understanding of hash functions in 2003. Meow. The protocols mostly work, except when they don't. The software is crap. It's been nearly fifteen years since Drew Gross enlightened me by saying, "I love crypto; it tells me what part of the system not to bother attacking." Look at it anthropicly. We know the crypto works because the adversary says they're looking at metadata. To phrase that differently, they're looking at metadata because the crypto works! Look at things like Fishbowl, even. It's easy to get dazzled by the fact that Fishbowl is double encryption to miss that it's really double *implementations*. The crypto works. The software is crap. Think like the adversary. Put yourself in their shoes. What's cheaper, buying a 'sploit or cracking a cipher? Once you start buying 'sploits, why not build your own team to do them yourself, and cut out the middleman? Every other part of the tech world has seen disintermediation, what makes you think this is different. On the other end of things, there's traffic analysis. We have seen -- stuff -- from them over the last decade. Papers on social graph analysis, pattern analysis. Emphasis on malware, validation, and so on. Here's another analogy. Imagine that you're looking at a huge, fantastically complex marching band. You're trying to figure out who all is doing what to what parts of the music and it's horribly complex. And then accidentally one day, you lose the audio feed and then realize that it's *easier* to tell what the band is doing when the sound is off. Aphasiacs are (so I am told) good at telling truth from lies because they look at the face rather than listen to the voice. They analyze the metadata, because they can't hear the data and it works *better*. Traffic analysis is what you do if your feed from the marching band loses its audio. It's what you do if you're aphasiac -- which is *exactly* what happens when the crypto works, by the way. Thus with a large budget, you do both. With one hand, you crack the crypto by cracking the software. When it works it works. When it doesn't, it doesn't. Stop stressing. With the other hand, you revel in the glory of silence. In silence you can think. You watch the band, you watch square dance. You just watch who is pairing with whom, where the lines cross and the beats are. Sometimes you can even guess the tune by watching the dance (which is also cryptanalysis). And all of that is why the problem in email isn't the crypto, it's SMTP. Jon

On Aug 31, 2013, at 1:05 AM, Adam Back <adam@cypherspace.org> wrote:

More precisely its the exposed meta-data in the SMTP. But why would you use meta-data rich transport for silent circle internal-mail? (Internal-mail I mean silent circle user to silent circle user vs external mail being smtp mail to silent circle user or silent circle user to smtp mail user).

I said it before, but again: why not cancel external mail, and leave the internal mail working - silent circle obviously have the tech for that because they have SMS equivalent in-mail. Good for you: users who want to continue to communicate will encourage the people they are communicating with to also pay for subscriptions. Maybe you could allow people to give each other gifts of 1month membership, which you hope they extend themselves; or some referal system with a bonus free month to the existing user etc.

Now there might be some software legacy, but that seems straight forward enough. The crypto gap is purely the in and out mail. (Other than forced software changes, but others have discussed how to combat that issue, and some claim legal advice is that its harder for the mil-int community to legally force companies to change their software. (Hushmail saga not withstanding!)

I believe that when one is on a team, the more senior one is on the team, the more one has the responsibility to discuss the *team* decision even when one's opinion was different. Actually, *especially* when one's personal decision was different. Every decision has reasons for and reasons against. One's job as a senior team member is to talk about the way one came to the decision for, and not about the reasons against. I just had a short conversation with Mike Janke about this issue and this discussion, and with his leave I'm going to go against my normal beliefs. Silent Circle is Mike's vision. He did physical security in a variety of countries and saw that people who are expats from anywhere in anywhere else have a lot of issues they have to face that are all secure communications. Moreover, these people are told "no" all the time (don't use Skype, don't use Gmail, don't trust SMS, don't use cell phones, landlines) and never "yes." The initial vision of Silent Circle was to give those people a "yes." There are (were) three pillars of that vision to give people yesses -- voice/video/etc., texting etc., and email etc. When I wrote that the email was "something of a quandary," that means that Mike was always for it and I was always against it. I see the other side of it and believe that something that's email-like is essential. We have an architecture for how we're going to grow texting into "messaging" and that will be email-like with true end-to-end security for internal mail. It is a ways off. There are lots of things to work on, from user experience to syncing across devices -- each with real security. In the meantime, what do the users do? We did a lot of talking to end users, and what they want and need is more than just internal email. They need it to be connected to the Internet. Part of the use case includes that someone wants to send a subscriber a PDF of an insurance form, rental agreement, or so on that the subscriber needs to print out, sign, scan, and send back. A number of them said that what they really wanted as much as anything was an email system run by people who give a damn about security as much as the crypto itself. Whatever that means. Mike was (and is) a happy customer of one of the existing secure email systems for years, understood its limitations and thought that a useful system could be made out of a conventional email infrastructure augmented by PGP Universal. I was on the other side. PGP Universal is designed for a different use case, a different threat model, blah, blah, blah. You've heard me say it, so I won't repeat it. When I rationally looked at the facts of the situation, Silent Mail's proposed security was *different* than other secure email systems, but similar. If someone uses it "securely" then it's very good, and when they use it "conveniently" it isn't worse than any of the other convenience-minded secure email systems. Moreover, and getting to the real brass tacks here, Mike's the boss. It's his dream and his money funding it. As an interim system to have, it isn't that bad. Additionally, one of my bugaboos about security is something I call "security arrogance." Security arrogance is when the security person tells the users what their threat model should be. It's closely related to another thing I talked about a decade ago that I called "the security cliff" -- you start with no security and to get to security, you have to climb a cliff rather than ascend a ramp in that you can't stop halfway up. I believe that one of the ways we security people shoot our clients in the foot is to focus on the ways that security is imperfect and thus argue that less-than-perfect security is worse than no security. Okay, fine. Hoist by my own petard. Silent Mail, ho! I'll also add that other team members were of course, spread all over the essential quandary here from thinking it was wonderful to being conflicted to thinking that Silent Mail was worse than nothing. Development-wise, we had some plans to improve Silent Mail -- specifically, one of the tasks was to make a network widget that would scrape offending headers out of SMTP. However, note that we're a startup. Life is not a zero-sum game, but development is. Every iota of effort that's spent propping up SMTP is an iota that's not going to making its replacement. This ended up being a different sort of quandary. The people who accepted Silent Mail warts and all (or shock, horror liked it) like the idea of the new "messaging" system even better. Thus, propping up SMTP didn't really have any champions, and it's not like we have people sitting around doing nothing. We all considered Silent Mail to be a stop-gap. Let me fast-forward up to the day before we shut Silent Mail down. One of the major requests that we had was to split the suite of products up. We were working on precisely that. (And it should go live next week.) In fact, we were *discussing* a breakup of the suite even before Silent Mail went live, and we noted that it became a legacy product after being up for about a week. As there was more and more news about state-sponsored espionage (China, Countries Starting With The Letter 'I', etc.), we got more "business" customers and they were as a rule not interested in secure email that was not under the direct control of their own IT. Post-Snowden, the people who thought, "It's good enough" became fewer. The proportion of users who were using Silent Mail was about 5% of the total. Every account has a page where you set up your devices, and there's a link to click to set up Silent Mail. Only people who clicked that link got set up, and the 5% number is the people who set it up, so that's obviously an upper bound of people using it. We had been discussing shutting it down -- that 5% figure is either an argument for why it just isn't succeeding as a product, or an argument why the people who are using it understand it and its limitations. It was a discussion item for our September BoD meeting. My plan was to suggest we stop taking new orders and subscription renewals as part of the suite break-up, and then just let it fade away. I was, in fact, lobbying hard for that. I believe I would have prevailed at the board meeting, but of course I'd think that. Your suggestion about making it be internal-only was something I'd be willing to compromise on. However, remember that much of the whole *point* of Silent Mail is that it's a well-run Internet Email System. Now let's get to the day we shut it down. I had been at the VoIP conference, ClueCon, in Chicago. As luck would have it, I finished up early and failed to get standby on an early flight home. Others of us were scattered with other travel. One of my major thoughts was what if there's paperwork on its way, and that paperwork doesn't know I'm in an airport lounge? When I finally got Mike on the phone, he said, "You did the right thing. I'm glad you're my partner." Interestingly, the guys who work for me told me after that they had decided that they would delete things themselves if things went on for another couple hours. I know this has been long, so let me sum up answers to your questions: * Silent Mail was always a debate between perfect and good enough. It was even a debate over what it means to be good enough. * The people who thought it was good enough don't think like you and me, and I think their point of view has it's own validity. * The people who wanted it wanted it to be an Internet Email System above all. Even in the design of the new thing, it has to be connected to the Internet so that someone on the Internet can send you an email. Pulling back to being internal-only would not meet the goals of the people who wanted it. * We're a startup. We only have so many resources, and no one was the champion of making Silent Mail better. The people who thought it was good enough didn't see the point in making it better, and the people who thought it wasn't good enough didn't see the point either. I hope this helps explain. Jon

On 2013-08-30, Jon Callas wrote:

The crypto is the easy part. The hard part is the traffic analysis, of which the worst part is the Received headers.

So, how would one go about a gateway which strips all of it on the way into/out of an onion router, without jeopardizing that basic functionality which can at all survive after anonymization? At least to me it would seem that you can't adopt a firewall mindset where you just blacklist/shave-off certain features and options. If you want to be certain, you'll have to have an exacting parser which only accepts as an input language something "clean". Probably on the pain of rejecting a whole lot of otherwise common or even valid emails and such. Has anybody tried to write a truly anal parser/normaliser/rejecter to date?

There are plenty of other leaks like Message-ID, Mime-Version, X-Mailer, the actual separators in MIME part breaks, and so on.

All except Message-ID can be dropped without jeopardizing service. Message-ID, well, that's just such a basic part of the service that you'd have to go with zero knowledge proofs in a funky and expensive way if you wanted to get rid of that one.

It's absolutely correct that some combination of VPNs, Tor, remailers of whatever stripe, and so on can help with this, but we're all lazy and we don't do it all the time.

We need them *too*. Doesn't mean we shouldn't sanitise our outgoing (and incoming, because of replies) email all the same. Automatically. With minimum hassle. On as many platforms as needed.

What we're learning from Snowden is that they're doing traffic analysis -- analyzing movements, social graphs, and so on and so forth.

True Names. They're now there. So let's deal with the problem.

The problem isn't the crypto, it's SMTP.

Yes, SMTP is the basest problem. It's difficult to get around envelop addresses in the clear and all that. But above you talked about something within the protocol which *can* be sanitised. Let's do that, programmatically, at least, and right now. After that, it's suddenly *much* easier to deal with the address on the envelope. -- Sampo Syreeni, aka decoy - decoy@iki.fi, http://decoy.iki.fi/front +358-40-3255353, 025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2