[messaging] Keyservers discussion - Day 1 highlights

[Tom Ritter]

On 19 August 2014 03:18, Trevor Perrin <trevp at trevp.net> wrote:
> Yet I'd ALSO claim the provider is one of the most
> important entities for end-to-end crypto to protect us from.
> Conundrum.

When you don't trust your provider, I think that can be roughly
analogized to trying to solve the present-day CA system while
acknowledging they're not going away.  The best we've seen come up
with is CT.  It's a 'Trust but Verify' model, except those who verify
are very few.  The extension of this, I mentioned a few months ago:

On 26 March 2014 08:17, Tom Ritter <tom at ritter.vg> wrote:
> A design I keep circling back to, despite not liking it all that much,
> is a 98% Trust, 2% Verify model. It needs a new name, but the idea is
> open specifications, and open ability to write outside clients that
> interop that you trust more. The outside client may be browser
> extensions silently verifying the code, extensions providing the whole
> experience, mobile apps, native apps, whatever.  The 2% run these
> outside clients and don't 'trust' the service to do the encryption,
> the 98% use provider-bootstrapped code that can be tampered with.
> Delicately designed, on an individual request, the service shouldn't
> know who is the 2% vs the 98% until it's too late to undetectably
> tamper. On repeated observations, the service may know, but I think
> this can be mitigated a little bit.


> Elijah criticized the idea of applying CT to the "user key problem"
> [3].  I think the crux of his argument is that we want anonymized key
> lookup for relationship-hiding anyways, so we can use that for
> auditing (like Nyms).  CT doesn't "add enough benefit to justify the
> complexity".

I don't think we've fully explored the possibility and capability of a
network of interconnected, blinding services that perform key lookup.
Convergence experimented with this a little, but didn't optimize it.
What I imagine:

Providers A & B run at least 2 servers each, co-locating one of theirs
in the same datacenter. They keep a long-lived TLS session open to
each other.  I make a request to A, encrypted to B. A immediately
passes it to B, which answers and re-encrypts, passing it back to me
through A.

Other mechanisms like PIR of course exist for anonymized key lookup,
but my first thought was 'make it really fast'.

-tom