On 5 October 2014 20:22, Trevor Perrin <[email protected]> wrote: > 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
Nice. I think I broadly agree with all of the above. >>> *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?). Yes, but note that the MMD is a backstop - it has to be long enough to make it possible to fix operational problems - in practice, publication is much faster. >>> 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. Precisely. OK, I get that being able to, for example, verify keys when I physically meet someone is helpful, its the exception rather than the rule - even for someone like me who understands what verification is and what it is for. In practice, I think the only currently verified key for TextSecure I have is for my wife. And that's possible because we live in the same house... > 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). I am objecting to the idea that there are OOB channels available to most people, rather than the idea that verification is a good thing. _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
