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

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A different approach is to have Bob's service provider, as specified<br>
in his username, be his keyserver (LEAP, STEED, UEE).  For example,<br>
the keyserver for <a href="mailto:bob@example.com">bob@example.com</a> would be <a href="http://example.com" target="_blank">example.com</a>.  This<br>
eliminates the coordination problem, makes registration easier (Bob<br>
authenticates to his provider), *might* address the incentive problem<br>
(Bob's service provider would run the keyserver as part of providing<br>
him service), and gives Bob flexibility to choose the keyserver (by<br>
choosing his provider).<br>
<br>
Of course, now Alice needs to authenticate <a href="http://example.com" target="_blank">example.com</a>.  A DNS<br>
solution (DNSSEC or DNSCurve) seems elegant - if <a href="mailto:bob@example.com">bob@example.com</a> is<br>
vouched for by <a href="http://example.com" target="_blank">example.com</a>, then <a href="http://example.com" target="_blank">example.com</a> could be vouched for by<br>
com, who's vouched for by the DNS root.  But since <a href="http://example.com" target="_blank">example.com</a> is a<br>
public server with administrators, it has plenty of other options<br>
(HTTPS certs, CT logs, pinning via HPKP/TACK or curated pin lists,<br>
etc.).  So we can handwave "Alice authenticates <a href="http://example.com" target="_blank">example.com</a>" as being<br>
solvable a bunch of ways.<br></blockquote><div><br></div><div>+1 on this. See also: DANE for X.509, and WebFinger for tying profiles to their email provider.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

A sharper criticism is that changing providers and usernames is<br>
costly, so Bob's flexibility is limited.</blockquote><div><br></div><div>This is going to be true of whatever scheme you use, unless you have a convenient mechanism for bootstrapping a new identity from an old one, but that could be exploited by attackers in an account takeover scenario to transfer control of someone's identity to an attacker-controlled account.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There are also protocol design questions that could be tackled<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


independent of who runs things, e.g.<br>
 * How to make keyservers auditable</blockquote><div><br></div><div>I think whatever the solution is, it needs a CT-like scheme to help detect spoofed IDs.</div><div><br></div><div>I think a CT like system is the sort of thing people expect out of a web-of-trust, except instead of relying on random people to be the trust anchors, you depend on services run (and hopefully hardened) specifically for this purpose. <br>

</div></div><div><br></div>-- <br>Tony Arcieri<br>
</div></div>