<div dir="ltr">Thanks all for your detailed replies. I'll try and comment on all these, apologies on the order. I'm interested to hear your thoughts on my (opinionated) position as I most definitely am surrounded by an echo chamber IRL :)<div><br></div><div><br></div><div>WRT email addresses as a primary identifier, I have concerns:</div><div><br></div><div>This wins the UX game because emails are memorable, short and can be put in an existing users contacts. SNs and hash-based proposals arent memorable, but thanks to the prevalence of deeplinking and QR codes, they can be trivially shared by users. Snapchat did this and proved the effectiveness of this UX.</div><div><br></div><div>The main failing of emails as an identifier IMHO is that we now make the security properties of our identifier constrained by the security properties of email. This is a solvable problem with the correct use of TLS and various DNS records, but this is non-trivial. I would much rather side-step all of this. Solving that with shadow registries and the like address the problem but multiplies complexity and subsequently the number of failure modes. This further compounds difficulties when constructing a threat matrix or a user/org reasoning against their threat model.</div><div><br></div><div>Also, homoglyph attacks are possible on anything a user could recognize (email identifiers, usernames), and these are terrifyingly easy to pull off. Just this attack alone imo means we need to stop relying on users (ie: do I recognize this email address) for verification and exclusively use 1) artifacts that dont rely on humans and 2) computers for verification. Phishing is well understood by researchers yet highly effective (whelp).</div><div><br></div><div>My last issue with email is provenance. Even though throwaway email addresses are easier than throwaway phone numbers, adversaries still have something to follow up on.</div><div><br></div><div>WRT recovery - "phone droped into toliet" use-case:</div><div><br></div><div>Beyond the obvious (backup your keys somewhere), I dont have a good answer for this. The best UX here would be some artifact you store offline ('print' a QR code, download to a USB stick) but this has its own set of issues.</div><div><br></div><div>At some level this is an inherent problem of online identity, and by keying off email addresses, we are only deferring the problem to the email password/2FA/recovery-mechanisms. Personally, I rather the trade-off where we address backup ourselves.</div><div><br></div><div>We can also explicitly not address this: By explicitly stating our alternative identifiers are non-recoverable if you loose key material, and you accept this trade-off. This is okay as phone-based identifiers remain an option for users who dont lean this way.</div><div><br></div><div>Thanks all,</div><div>-T</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 28, 2018 at 4:28 PM, Max Skibinsky <span dir="ltr"><<a href="mailto:max@skibinsky.com" target="_blank">max@skibinsky.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"><span class="gmail-"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I've written it up on the signal forums here: <a href="https://community.signalusers.org/t/a-proposal-for-alternative-primary-identifiers" target="_blank">https://community.signal<wbr>users.org/t/a-proposal-for-alt<wbr>ernative-primary-identifiers</a></div></div></blockquote><div><br></div></span><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Trevor, we actually implemented simular schema few years ago in "Zax" relay: <a href="https://github.com/vault12/zax#readme" target="_blank">https://github.com/vault12/zax<wbr>#readme</a> Address space is global for all, address is a hash of a public key, and initial key exchange bootstraps via SMS (<a href="http://bit.ly/zax-invites" target="_blank">http://bit.ly/zax-invites</a>)</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">IMHO, the elephant in the room here is highly popular use case "phone droped into toilet", which is about few times a year for a casual user. As long as you need to support fresh phone bootstrap for casuals then phone number remain "casual ID" - goes without saying casual user has no clue how to backup her old phone, and she long forgoten whatever sequence of letters you told her 4 months ago. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Right now everyone accepts the compromise of having one instant of weakness (when phone number bootstraps long term PKI exchange) for the security of continious operations after such bootstrap took place. Whatever solution you end up doing it has to address the critical use case of user getting completely fresh phone, no old artefacts preserved, and the only connecton to his "past life" is his phone #. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">- Max<br>- <a href="http://vault12.com" target="_blank">vault12.com</a></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small"><br></div><br></div></div></div></div>
</blockquote></div><br></div>