<div dir="ltr">I agree completely with Moxie's points about the inadequacy of the proposed CT mechanism against detecting the expected government coercion. The point I was trying to make was CT needs to be analyzed in the context of its implicit threat model. The lawyers might also be barrier to make the threat model fully explicit. It is probably best if employees of public companies do not talk publicly about thwarting lawful interception. The proposed CT mechanism might meet the bar necessary for the lawyers to let us have our escrow free E2E communications from a giant tech company but might not actually offer greater protection than out of band key verification when we encounter a complicit key server. I caveat my thoughts with the observation that the term "Identity Provider" is poorly defined in the protocol and depending on the attributes of identity providers could either improve or worsen the situation considerably. <div class="gmail_extra"> <div class="gmail_quote">On Thu, Aug 28, 2014 at 1:20 PM, Moxie Marlinspike <<a href="mailto:moxie@thoughtcrime.org" target="_blank">moxie@thoughtcrime.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div> On 08/28/2014 12:33 PM, <a href="mailto:zaki@manian.org" target="_blank">zaki@manian.org</a> wrote: > In the CT case, the universe of cryptofolks can review anyone's account > history for evidence of a MITM attack after an attack has taken place. </div>What I'm confused about is, where's the evidence? If the cryptosystem is truly "invisible" to the user (as it should be!), these keys are going to be changing a lot, especially for users who aren't terribly crypto-literate (ie: Glenn Greenwald). I'm not sure that we can count on the "the crypto few" to monitor the security of others if there's not really definite proof for them to be looking for. I think it invites the perfect storm of reasonable apathy + wingnut conspiracy theory. <div> > In the TOFU case, it is only an MITM attack on one of the cryptofolks > that is likely to be discovered. > > The base case we are looking at is some like Glenn Greenwald circa 2012. > He deals with sensitive information but isn't terribly cryto-literate. </div>In the legal coercion case: It seems that in the CT world Google could say "Greenwald is a high profile journalist, it's possible that third parties are monitoring the CT log for his activity. Performing this MITM could damage our business." In the "simple thing" world, it seems that Google could just as easily say "Greenwald is a high profile journalist that takes the security of his communication seriously, it's possible that he is watching for key conflicts. Performing this MITM could damage our business." They seem almost exactly the same from the legal coercion perspective, if that's what you're designing for. <div> > Curious outsiders individuals would observe these events and the logs > would reveal that Google changed the key for <a href="mailto:ggreenwald@gmail.com" target="_blank">ggreenwald@gmail.com</a> </div>> <mailto:<a href="mailto:ggreenwald@gmail.com" target="_blank">ggreenwald@gmail.com</a>> 24hrs prior to his arrest. This would <div>> provide a piece of evidence that Google was either willfully > facilitating lawful interception or losing court battles that it fought. </div>The log would reveal that the key changed, not that Google changed the key. The log would also reveal that the key has changed many times before. Was this a conspiracy or a coincidence? We don't know. The only person that knows is the user. <div> > In the TOFU model, the community would only learn that Google became > untrustworthy is they attempted the same attack on the kinds of folks > that are on this list. The much smaller subset of the users especially > if the usability problems of crypto are largely addressed. </div>In order to say that "the crypto few" can effectively safeguard the communication of "almost everyone," I would need some more information on how exactly that would work. If I am one of "the crypto few," I don't see how I would effectively do this monitoring. The properties and tradeoffs between CT and "the simple thing" feel roughly the same to me, but one is way more complex than the other. - moxie <div> > On Thu, Aug 28, 2014 at 12:11 PM, Moxie Marlinspike </div>> <<a href="mailto:moxie@thoughtcrime.org" target="_blank">moxie@thoughtcrime.org</a> <mailto:<a href="mailto:moxie@thoughtcrime.org" target="_blank">moxie@thoughtcrime.org</a>>> wrote: <div><div>> > > On 08/28/2014 11:51 AM, <a href="mailto:zaki@manian.org" target="_blank">zaki@manian.org</a> <mailto:<a href="mailto:zaki@manian.org" target="_blank">zaki@manian.org</a>> wrote: > > The purpose to CT is not to protect users from MITM attacks. The > purpose > > of CT is protect the operators of key directories from coercion > and the > > network from malicious/subverted key directory operators. CT will > permit > > a response that complying with a lawful interception order will result > > in a significant loss of business for a directory operator. Keys > will be > > non-repudiable and thus it will clear after an adverse event who > > facilitated the MITM attack. > > > > Specifically, Google and Yahoo are large commercial entities that want > > to operate an encrypted communication network without key escrow in a > > way acceptable to their lawyers. The current operators of large e2e > > networks(iMessage, BBM) use key escrow as part of their compliance > > regime with lawful interception orders. > > Even in that context, I'd love to hear why you think "the simple thing" > doesn't accomplish the same goals. > > > "Keys will be non-repudiable and thus it will clear after an adverse > event who facilitated the MITM attack." > > I still don't understand how this is true. All that "we" see is that a > key changed, which is a completely normal event and will be happening at > a rate which is probably difficult for "us" to even keep up with. All > "we" really have is the word of the user that something in the log is > inappropriate. I don't see any other real definitive "proof." > > So what's the difference between CT and "the simple thing?" In both > cases, all we have is the word of the user that something they claim to > be amiss is amiss. > > > "CT will permit a response that complying with a lawful interception > order will result in a significant loss of business for a directory > operator." > > It seems like, in the CT case, the provider is essentially saying "by > performing this MITM attack, the user *could* be one of the few that > notices, in which case we'd be in big trouble." > > Isn't this just as true for "the simple thing?" The provider can say > "listen, this user's client *could* alert them to a key change, in which > case we'd be in big trouble." > > They seem to offer roughly the same "legal coercion" properties, but the > CT scheme is way more complex, doesn't offer realtime MITM protection, > has a spam problem, and will likely result in the provider being falsely > accused on a regular basis. The false accusations might even weaken the > "legal coercion" case, if they're frequent enough. > > - moxie > > > > On Thu, Aug 28, 2014 at 11:18 AM, Moxie Marlinspike > > <<a href="mailto:moxie@thoughtcrime.org" target="_blank">moxie@thoughtcrime.org</a> <mailto:<a href="mailto:moxie@thoughtcrime.org" target="_blank">moxie@thoughtcrime.org</a>> </div></div><div><div>> <mailto:<a href="mailto:moxie@thoughtcrime.org" target="_blank">moxie@thoughtcrime.org</a> <mailto:<a href="mailto:moxie@thoughtcrime.org" target="_blank">moxie@thoughtcrime.org</a>>>> wrote: > > > > > > On 08/27/2014 12:32 PM, Tony Arcieri wrote: > > > They plan on having email providers run "Key Directories" > and using > > > encrypted messages to gossip data about the directories, > providing a > > > CT-like system: > > > > > > <a href="https://code.google.com/p/end-to-end/wiki/KeyDistribution" target="_blank">https://code.google.com/p/end-to-end/wiki/KeyDistribution</a> > > > > I still have some questions about this approach. My understanding > > is that: > > > > 1) The monitors themselves can't determine whether Google is being > > "dishonest," beyond one extremely coarse view of whether Google is > > publishing an appropriate data structure. > > > > This is because: > > > > a) Users' keys will be changing constantly under completely normal > > circumstances. > > > > b) From running a service that operates as a sort of "key > directory," I > > know that many times they will even be changing in > "suspicious" ways, > > ie. from A to B and then back to A again. > > > > This means: > > > > 2) Users are the only ones who have the information to > determine whether > > Google is being dishonest. > > > > This is because: > > > > a) Users are the only ones who know what their keys actually > are, and > > whether they were supposed to change. > > > > So we're in a situation where the best a "monitor" can do is > provide the > > user with a view of their key state over time, which the user > can verify > > with their own knowledge of what their key state should be. > Nobody can > > detect an attack but the user themselves, which they depend on > a third > > party service in order to be able to do. Everything is > dependent on the > > user. > > > > I think there are three distinct classes of users: > > > > i) Almost everyone. In the world where all GMail customers are > using > > E2E, the vast majority of them won't (and shouldn't be > expected to) know > > what their key state should be, or what a key even is. So for > those > > users, Google can make whatever key changes they want with > impunity, and > > neither the "monitors" nor the users would be the wiser of > Google's > > nefarious ways. This may be OK, particularly if there's no > way for > > Google to distinguish between types of users. > > > > ii) The crypto few. There is a small percentage of users who > will know > > what a key is and understand how this works well enough to be > able to > > effectively monitor these changes. > > > > iii) Wingnuts. Larger than the crypto few, but still a vast > minority. > > They'll know what a "key" is, but won't *really* understand > how this > > works, and will become convinced that Google has MITMd them > when their > > key changed under normal circumstances. > > > > I don't see any way to distinguish the "wingnuts" from "the > crypto few." > > If either user steps forward to declare that their key was > compromised, > > the only information we have is the log. However, the user is > the only > > one with the information to determine whether the log is > correct or not, > > so there's no real "proof" other than the user's word. Even > with all > > the monitoring infrastructure available, there's still no > information > > that a 3rd party can use to determine whether a key was > maliciously > > inserted or not. > > > > That doesn't really seem to add up to a great situation. As I > see it: > > > > 1) This is a *lot* of work. Servers have to maintain these > directories > > at volumes (hopefully all gmail users) that are already difficult > > enough. Other organizations will need to be formed with somewhat > > considerable resources in order to effectively keep up with the > > monitoring. > > > > 2) Users can be successfully MITM'd, and will only learn about > it after > > the fact. > > > > 3) It creates a potential SPAM problem. > > > > 4) It creates a potential reputation problem for the key > directory, > > since "wingnuts" will constantly be announcing that they've > been MITM'd > > (complete with "proof" in the form of the log), and there'll > be no way > > for us to distinguish them from "the crypto few." > > > > So my question is, how is this better than doing the following: > > > > 1) Transmitting identity keys in-band. > > > > 2) Doing TOFU for keys seen. > > > > 3) Make the client notifying the user when a key changes, if > the user > > has a key change notification preference set. > > > > 4) Leaving the key change notification preference off by default. > > > > It seems to me that this has the same security properties as > the CT-like > > system, except: > > > > a) A *lot* less work, and a lot less complex. No need for other > > organizations to form. > > > > b) Both "wingnuts" and "the crypto few" are notified > immediately of a > > MITM rather than after the fact. "Almost everyone" remains > blissfully > > unaware, but again maybe that's OK if there's no way for the > provider to > > know with certainty which category a user is in. > > > > c) It's harder for wingnuts to get confused. > > > > d) No SPAM problem. > > > > I'm really interested in hearing why partisans of the CT-style key > > directory think the overhead and other drawbacks are worth > doing it over > > the simpler thing? > > > > - moxie > > > > -- > > <a href="http://www.thoughtcrime.org" target="_blank">http://www.thoughtcrime.org</a> > > _______________________________________________ > > Messaging mailing list > > <a href="mailto:Messaging@moderncrypto.org" target="_blank">Messaging@moderncrypto.org</a> <mailto:<a href="mailto:Messaging@moderncrypto.org" target="_blank">Messaging@moderncrypto.org</a>> </div></div>> <mailto:<a href="mailto:Messaging@moderncrypto.org" target="_blank">Messaging@moderncrypto.org</a> <mailto:<a href="mailto:Messaging@moderncrypto.org" target="_blank">Messaging@moderncrypto.org</a>>> <div><div>> > <a href="https://moderncrypto.org/mailman/listinfo/messaging" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a> > > > > > > -- > <a href="http://www.thoughtcrime.org" target="_blank">http://www.thoughtcrime.org</a> > _______________________________________________ > Messaging mailing list > <a href="mailto:Messaging@moderncrypto.org" target="_blank">Messaging@moderncrypto.org</a> <mailto:<a href="mailto:Messaging@moderncrypto.org" target="_blank">Messaging@moderncrypto.org</a>> > <a href="https://moderncrypto.org/mailman/listinfo/messaging" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a> > > -- <a href="http://www.thoughtcrime.org" target="_blank">http://www.thoughtcrime.org</a> _______________________________________________ Messaging mailing list <a href="mailto:Messaging@moderncrypto.org" target="_blank">Messaging@moderncrypto.org</a> <a href="https://moderncrypto.org/mailman/listinfo/messaging" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a> </div></div></blockquote></div> </div></div>