<p dir="ltr"><br>
On 18 Dec 2014 17:02, "Guido Witmond" <<a href="mailto:guido@witmond.nl">guido@witmond.nl</a>> wrote:<br>
><br>
> On 12/17/14 18:26, Tony Arcieri wrote:<br>
> > In an E2E-like system, Johnny's computer stores the private key, not the<br>
> > provider. The threat which would circumvent the encryption is a MitM<br>
> > attack perpetrated by the key-directory-who-is-also-his-email-provider.<br>
> ><br>
> > If we want to detect this attack without Johnny having to know about<br>
> > keys, we need a way that Johnny's agent can detect that the directory is<br>
> > misadvertising his public key to others without forcing Johnny to go<br>
> > through a key verification process with the people he's communicating with.<br>
><br>
> I've came up with a protocol that lets the user agents detect if their<br>
> key-directory is MitMing them.<br>
><br>
> It takes a round trip of one message each and sufficient time to<br>
> propagate the certificates though the out-of-bound<br>
> certificate--uniqueness-validation-service. I've called it the registry<br>
> of dishonesty....<br>
> <a href="http://eccentric-authentication.org/eccentric-authentication/global_registry_of_dishonesty.html">http://eccentric-authentication.org/eccentric-authentication/global_registry_of_dishonesty.html</a><br>
></p>
<p dir="ltr">I designed something similar but with a difference. A point to point MitM which does a back to back attack is still possible and much harder to detect. I conceived the system to work within social networks. (or if you prefer, phone book) </p>
<p dir="ltr">> The beauty of validation service is this:<br>
><br>
> The agents need to validate this MitM-status only at the moment the two<br>
> users want to communicate. After it is clear that there is no MitM, the<br>
> agents record that fact and remember it. The agents make sure to always<br>
> use the proven certificate to encrypt messages to the other. There is no<br>
> way for the key-server-annex-email-provider to MitM these two endpoints<br>
> ever.</p>
<p dir="ltr">The tricky part here is that if you are able to discern who is making the request for public key data then you could insert pairs of false public keys AND ONLY to those clients you are trying to MitM. One for client A and one for Client B. </p>
<p dir="ltr">That way your directory 'looks clean' to others. Worse still if the subsequently negotiated session key is long lived you don't need to MitM it all the time. You get around this by ALSO signing the messages but in my world that was annoying because of the cycles that eats (or in my use case the battery power that consumes) but I couldn't see a way around that. A bit like you you want immediate detection not relying on your next session key renegotiation to stand another chance picking it up. </p>
<p dir="ltr">The protocol I designed dealt with this attack by having the idea of authenticated directory querying and anonymous directory querying before I realised that actually 'anonymous' was pointless because that puts a massive burden on the system to actually enable anonymous access. </p>
<p dir="ltr">The other component was to Co opt people to help you validate keys. So I do the verification (much like you describe) and at negotiation time I also (and I think this is probably where our schemes differ) I ask others to tell me what their view of the key is. They can do this a number of ways. Through asking the directory, or by prior knowledge or both or even copting others into the question.</p>
<p dir="ltr">You can then build a mesh of 'viewpoints'. </p>
<p dir="ltr">That mesh is a really interesting beast. Pick other verifiers at random? Or people you trust? Or people who might know the person already? I'm doing *alot* of thinking about this property. </p>
<p dir="ltr">You seem to maintain a 'trust memory' a bit like I do. </p>
<p dir="ltr">The other thing was I introduced the idea that you put a 'watch' on the public keys of people you know *and* the directory needs to publish a CT like transparency chain. When you put a watch on you start your 'trust memory' at that point and you add meta data to your own record when you have your own conversations with these people. </p>
<p dir="ltr">When  you ask for someone's viewpoint on a public key. That can include the CT chain, from when you remembered it, when you last used it and what the trust mesh looks like. </p>
<p dir="ltr">What this does is make the global MitM directory attack (1 fake key published to the world) easy to detect and the back to back pointed attack hard to execute successfully. Because you have to try to back to back the MitM attack the entire mesh and hope nobody has prior memory of the real key. </p>
<p dir="ltr">><br>
> Here's the requirements for such a validation service:<br>
> <a href="http://eccentric-authentication.org/blog/2014/03/26/how-to-design-a-distributed-client-certificate-verification-service.html">http://eccentric-authentication.org/blog/2014/03/26/how-to-design-a-distributed-client-certificate-verification-service.html</a><br>
></p>
<p dir="ltr">Cool! Similar but different 😊</p>
<p dir="ltr">Cheers<br>
Max </p>