[messaging] Thoughts on keyservers
bascule at gmail.com
Mon Aug 18 14:35:24 PDT 2014
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Messaging