[messaging] Keyservers discussion - Day 1 highlights

[Trevor Perrin]

On Tue, Aug 19, 2014 at 7:16 AM, Tom Ritter <tom at ritter.vg> wrote:
> 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.

Maybe, but I'm going to pick at the analogy:

The CA system for HTTPS is "not going away" because
 (a) it meets the constraint of zero additional lookups in the browser [1]
 (b) there's an entrenched base of browsers that expect it

Those arguments don't apply to provider-based key endorsement, so it's
not really a "forced move" in the way that CAs are.

You could argue that providers are necessarily part of the trust model
because they could falsely register public keys for their users.
That's a DNSSEC/DANE sort of argument:  DNS authorities could falsely
register HTTPS certs for websites, or interfere with anything based on
DNS names, thus they're "authoritative" for all these things and
should be the universal PKI.

I find that unconvincing:  when I send email to "alice at example.com"
the recipient isn't the email address, it's the person at that
address.  The fact that providers and DNS are between me and Alice
doesn't make them "trusted", it makes them things I want cryptographic
protection from.

That said, I agree that key directories that are provider-hosted or
populated by email registration could be a convenient and efficient
way to find keys.  I just think they should be viewed as "useful
infrastructure" more than "trusted infrastructure".  They should be
designed to make end-to-end crypto efficient and ubiquitous, while
providing a foundation for stronger things like TOFU, out-of-band
methods like fingerprints and SAS, auditing, multipath checking of
Keybase proofs, and so on.


> The best we've seen come up
> with is CT.

I dunno, even if so CT''s shaped around the Web PKI and needs
rethinking for this case:

For one thing, the benefits of auditing seem greater in the Web PKI
than the "audit your own keyserver" case: backwater CAs issuing certs
for major websites is a huge risk and should be obvious in CT logs.
In contrast, telling millions of webmail users to freak out whenever a
reporting service sends an unexpected "key change" notice could be
problematic [2].

CT is also shaped around HTTPS performance / operational constraints:
 * Due to (a) above, CT data in the TLS handshake needs to come from a
central set of logs
 * HTTPS servers don't want to wait before using a new cert
 * There's limited space in the TLS handshake

So instead of including audit proofs directly in the TLS handshake,
the handshake contains signatures from logs promising to publish the
cert in an upcoming snapshot, and browsers can download and check
audit proofs later.

Also, because CT is being bolted onto the CA system, it logs
statements about what certs exist, but not whether they're valid or
not, so it needs to be used with a revocation system, and the
relationship with that is complex.

Anyways, I'm not objecting to some sort of transparency here, there's
just a lot of unanswered questions about it.

Trevor

[1] https://moderncrypto.org/mail-archive/messaging/2014/000636.html
[2] https://moderncrypto.org/mail-archive/messaging/2014/000234.html