<div dir="ltr">An important difference between WebPKI and e2e messaging PKI is the expectation that the destination of the message is online and reachable when communication is desired. The common case for e2e messaging must be users on battery powered devices whose network access comes from radios. In webPKI, the destination server can be expected be online and collaborate in ephemeral key generation,etc. once authenticity has been established. In the e2e case, an intermediary server is necessary both to provide identity and to collaborate is managing prekeys, inboxes and other forms of state on behalf of the recipient. <br>

<br>In our current set of e2e applications, the function of PKI and state management is provided by the same entity. I'm primarily thinking of iMessage and TextSecure in this context. The primary disadvantage of this setup is intermediary server can engage in variety of malicious actions with little to no accountability. The low risk of discovery increases the probability that a malicious actor could coerce an otherwise trustworthy intermediary to facilitate a MITM attack,<br>

<br>The main goal in designing an e2e PKI infrastructure must be increasing the risks of malicious behavior on the intermediaries. The design should facilitate auditing both by the recipients and third parties. Yan's Transparency proposal addresses this well. One of the aspects of blockchain solutions that appeals to me is that blockchains are prior art on running large distributed append-only data structures served from thousands of independent nodes. <br>

  <br><br> </div><div class="gmail_extra"><br clear="all"><div><div dir="ltr">US number: +1 650-492-8286<div><a href="https://play.google.com/store/apps/details?id=org.thoughtcrime.securesms&hl=en" target="_blank">Text Secure</a>: +1650-862-5992</div>

<div>Surespot/Wickr: zmanian<br><a href="https://raw.github.com/zmanian/pub_keys/master/gpg/%3Czaki@manian.org%3E.public.gpg-key" target="_blank">Public Key</a></div></div></div>
<br><br><div class="gmail_quote">On Tue, Aug 19, 2014 at 3:36 PM, Tony Arcieri <span dir="ltr"><<a href="mailto:bascule@gmail.com" target="_blank">bascule@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="">On Tue, Aug 19, 2014 at 3:27 AM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br>



</div><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There may still be reasons to prefer a centralized system, or to use<br>
it in conjunction with other options.  But I think that needs to be<br>
justified on better grounds than "it worked for the web"</blockquote><div><br></div></div><div>It's easy to argue that the X.509 PKI used by the web has failed. However, it has provided users with a relatively seamless system that provides a barrier-to-entry for attacks. I'd place the emphasis on the former: by being mostly seamless, your average non-technical user has been able to partake of the security benefits in the common case, even if there are many known attacks that can be targeted at specific users.</div>



<div><br></div><div>I would argue that a usable secure messaging system needs to seek a similar level of seamless UX. Good security is like air: the only time you should have to worry about it is when it's missing.</div>

<span class="HOEnZb"><font color="#888888">

</font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div>-- <br>Tony Arcieri<br>
</font></span></div></div>
<br>_______________________________________________<br>
Messaging mailing list<br>
<a href="mailto:Messaging@moderncrypto.org">Messaging@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/messaging" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a><br>
<br></blockquote></div><br></div>