<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 28, 2014 at 3:11 PM, Moxie Marlinspike <span dir="ltr"><<a href="mailto:moxie@thoughtcrime.org" target="_blank">moxie@thoughtcrime.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="">
> Specifically, Google and Yahoo are large commercial entities that want<br>
> to operate an encrypted communication network without key escrow in a<br>
> way acceptable to their lawyers. The current operators of large e2e<br>
> networks(iMessage, BBM) use key escrow as part of their compliance<br>
> regime with lawful interception orders.<br>
<br>
</div>Even in that context, I'd love to hear why you think "the simple thing"<br>
doesn't accomplish the same goals.</blockquote><div><br></div><div>So with "the simple thing" proposed by Moxie (as I understand it), consider that one party will probably be both the Key Directory and Message Transfer Agent. So they can tell Bob that Alice's key is Y when it's really X, and when when Bob messages Alice they intercept and re-encrypt. If the KD has to sign all of its assertions, then Alice and Bob need to gossip out of band to realize the KD is equivocating. To prevent this you want Bob to sign what he thinks Alice's key is so even if Alice's KD changes the encryption, they can't forge Bob's signature assuming Bob's KD/MTA is honest.</div>

<div><br></div><div>If this were implemented and you could detect an equivocating server assuming at some point one of its users talks to another user who has an honest server. Two equivocating servers in cahoots could probably both equivocate if a pair of their users was talking. The log/monitor setup might be more resistant to this case, though you could similarly build out-of-band gossip onto the "simple thing" case and get part of the way there.</div>

<div><br></div><div>I think you can summarize all of the append-only log and monitor infrastructure as apparatus to ensure that equivocation will be detected. So perhaps either approach works at preventing equivocation and the "simple thing" might be appropriately named. Unless we're missing something?</div>

<div><br></div><div>Either way, I agree that on the hard questions of determining ground truth and not showing tons of spurious warnings we're exactly where we were when the last thread on messaging transparency[1] died in March. There are still painful edge cases like if Alice's client doesn't know that Alice enrolled a new device with a new key yet and warns that a spurious key has been added, which is I discussed over on Google's wiki for this project and haven't heard a compelling answer for.</div>

<div><br></div><div>On the issue of legal cover to avoid serving national security letters, hopefully Google's lawyers have thought this through and determined there's some real value. We're not any further on this mailing list towards answering that question either (which also came up before[1]).</div>

<div><br></div><div>[1] <a href="https://moderncrypto.org/mail-archive/messaging/2014/thread.html#226">https://moderncrypto.org/mail-archive/messaging/2014/thread.html#226</a><br></div></div></div></div>