[messaging] Thoughts on keyservers

[Tony Arcieri]

On Mon, Aug 18, 2014 at 12:09 AM, Trevor Perrin <trevp at trevp.net> wrote:

> A different approach is to have Bob's service provider, as specified
> in his username, be his keyserver (LEAP, STEED, UEE).  For example,
> the keyserver for bob at example.com would be example.com.  This
> eliminates the coordination problem, makes registration easier (Bob
> authenticates to his provider), *might* address the incentive problem
> (Bob's service provider would run the keyserver as part of providing
> him service), and gives Bob flexibility to choose the keyserver (by
> choosing his provider).
>
> Of course, now Alice needs to authenticate example.com.  A DNS
> solution (DNSSEC or DNSCurve) seems elegant - if bob at example.com is
> vouched for by example.com, then example.com could be vouched for by
> com, who's vouched for by the DNS root.  But since example.com is a
> public server with administrators, it has plenty of other options
> (HTTPS certs, CT logs, pinning via HPKP/TACK or curated pin lists,
> etc.).  So we can handwave "Alice authenticates example.com" as being
> solvable a bunch of ways.
>

+1 on this. See also: DANE for X.509, and WebFinger for tying profiles to
their email provider.


> A sharper criticism is that changing providers and usernames is
> costly, so Bob's flexibility is limited.


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.

There are also protocol design questions that could be tackled
>
independent of who runs things, e.g.
>  * How to make keyservers auditable


I think whatever the solution is, it needs a CT-like scheme to help detect
spoofed IDs.

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.

-- 
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140818/099c7b84/attachment.html>