On Sat, Oct 4, 2014 at 3:26 AM, Ben Laurie <[email protected]> wrote: > > > On 3 October 2014 22:35, Joseph Bonneau <[email protected]> wrote: >> >> Let me try to summarize this thread (as I understand it) since I've been >> lurking and I think there may be some connections between ideas missing. >> Here's an attempt at outlining how MITM detection would work in two >> discussed cases as I understand it: >> >> CT-style (I think we should call it CT-style to avoid confusion with >> Certificate Transparency proper for TLS certificates)
I've used "transparency log" to distinguish from CT proper. It's good to make a distinction, but these terms are vague enough there's still lots of room for confusion. For example: Q1) Does this mean using CT to authenticate the key directory itself, or are we just talking about user keys? A1) User keys is what we've been discussing, mostly - authenticating the key directory is separate Q2) Is each key directory running a single transparency log, or are they separate (like CT)? A2) Single log seems best, if you're designing a new system instead of retrofitting Web PKI Q3) Is the log just a list of things that have been published, with separate revocation (like CT) or an authenticated dictionary that publishes the latest correct entries? A3) Authenticated dictionary seems best, if you're designing a new system instead of retrofitting Web PKI Q4) Does this encompass any system where public-key data is published and analyzed by 3rd-party monitors, or only systems based on Merkle Trees? A4) Merkle Trees and the ability to "gossip" small signed-tree-hashes, then fetch proofs based on them, are the defining element of this approach. Q5) Does this encompass both centralized and provider-based key directories A5) Yes, though a world with lots of logs / key directories is challenging for "gossip" protocols >> *Alice looks up Bob's key. >> *The Evil Log inserts a spurious key for Bob. We're assuming (I think >> almost all of us are willing to assume this) that log-consistency auditors >> ensure the log has to actually put the spurious key into a globally >> consistent log forever. Trying to locally fork Alice's view is too risky if >> some non-zero proportion of users gossip out of band. > > > Then this is really the Evil Keyserver doing the inserting. Evil Logs would > presumably try other tactics... > >> >> *Later on (after up to the MMD) Bob gets a ping from his monitor that "a >> new key for Bob has been logged." Bob concludes that the Evil Log is evil. >> Alice learns nothing. > > > Don't forget the existence of an MMD is tradeoff - the original version of > CT required a log inclusion proof to be served alongside the cert. It would > be possible to do that for this (the price is new keys take longer to > generate). Hm, imagine Bob reinstalls the app, changing his key from X to Y. It would be bad if no-one could send him a message until the next log is published. So I think the CT strategy of Merkle-Tree snapshots necessitates a "post-facto" system as Joe describes, where there might be a delay before Bob's monitor can notice a change (I think Google's current CT logs have MMD = 24 hours?). >> The Simple Thing >> *Alice looks up Bob's key. Two versions seem to have been discussed at >> different points: >> Version (a)-Alice gets it directly from Bob over an untrusted >> channel. >> Version (b)-Alice gets it from a semi-trusted key directory/service >> provider for Bob's address. >> *In Version (a), a MITM simply changes Bob's transmitted key. In Version >> (b), the Evil Directory signs a spurious key for Bob and returns it to >> Alice. >> *Ideally, Alice asks Bob out-of-band if this new key is correct before >> sending anything. If so, Bob detects the attack and warns Alice not to send. > > > If there's this magical non-MITMable out-of-band channel, why is Alice not > using it to send the message to Bob in the first place? Well, think of dealing with fingerprints via scanning a QR code (TextSecure), SafeSlinger, tapping NFC phones together, reading a small hex string, etc. Of course, it's inconvenient for every pair of Alice and Bob to do this. So it's nice to have 3rd-parties that Alice can confirm Bob's key with. CT is one way to do this, but there are others (e.g. Alice could query monitors directly, instead of using gossip + proofs). Trevor _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
