On Tue, Aug 19, 2014 at 7:16 AM, Tom Ritter <[email protected]> wrote: > On 19 August 2014 03:18, Trevor Perrin <[email protected]> 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 "[email protected]" 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 _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
