[messaging] The Simple Thing

[Ben Laurie]

On 5 October 2014 20:22, Trevor Perrin <trevp at trevp.net> wrote:
> 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

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.