[messaging] The Simple Thing

[Trevor Perrin]

On Sat, Oct 4, 2014 at 3:26 AM, Ben Laurie <ben at links.org> wrote:
>
>
> On 3 October 2014 22:35, Joseph Bonneau <jbonneau at gmail.com> 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