[messaging] The Simple Thing

Sat Oct 4 13:49:52 PDT 2014

------ Original Message ------
From: "Ben Laurie" <ben at links.org>
To: "Nadim Kobeissi" <nadim at nadim.computer>
Cc: "Joseph Bonneau" <jbonneau at gmail.com>; "messaging" 
<messaging at moderncrypto.org>
Sent: 2014-10-04 6:36:06 AM
Subject: Re: [messaging] The Simple Thing

>On 3 October 2014 23:03, Nadim Kobeissi <nadim at nadim.computer> wrote:
>>
>>  I'd like to add, as another person who's been lurking this 
>>discussion:
>>
>>  For what it's worth, I think The Simple Thing has substantial value 
>>over other potential models due to its reliance on pre-existing 
>>architecture and pre-established norms.
>>
>>  The building blocks are already there: the infrastructure for key 
>>exchange, the norms for authentication, and so on.
>
>
>What are these "norms for authentication"? Isn't the underlying
>premise that most users can't do authentication currently?

They *can* in theory via OOB methods. They *don't* because OOB 
authentication is tedious unless you improve the ease-of-use aspect.

>
>>
>>  There isn't the need for setting up any new giant multi-tiered 
>>worldwide network for auditing and keeping various actors in check 
>>should they conspire to modify Bob's key. And I think this is more 
>>valuable than it seems to many people at first.
>>
>>  Some will say: "it doesn't matter! I have the will, the means and the 
>>energy to build my new CT-like system!" And my response would be: 
>>Great - why don't you use that energy to improve The Simple Thing, 
>>since its components and norms are *already in place* and all we have 
>>to do is make sure they're more user-friendly? Work on making out of 
>>band authentication easier, for example.
>>
>>  I'm doing work on authentication right now (more on this later) and 
>>I've already seen some promising work on this list in a variety of 
>>creative ways. By working towards a better (simpler?) Simple Thing, 
>>you'll be building on top of techniques that are established, on an 
>>infrastructure you can already wrangle, on algorithms that are simpler 
>>to implement from the programmer's perspective. Ease of use is 
>>literally *the only missing piece*, and I think projects like Moxie's 
>>work (look at how well Signal/Redphone does per-session 
>>authentication, for example) and also Cryptocat/miniLock are showing 
>>that we can make this happen.
>
>I've looked, but I can't find how Redphone, Signal, Cryptocat or
>miniLock do authentication ... pointers, please?
Here's a screenshot from a Signal call:
http://www.wired.com/wp-content/uploads/2014/06/signal.jpg

The two words, "hockey publisher" are being used to authenticate (they 
act as fingerprints of session keys.)

NK

>
>On the energy needed to build a CT-like system: we're already writing
>most of the code for CT, so it also is built on stuff that already
>exists...
>
>>
>>
>>
>>  NK
>>
>>
>>  ------ Original Message ------
>>  From: "Joseph Bonneau" <jbonneau at gmail.com>
>>  To:
>>  Cc: "messaging" <messaging at moderncrypto.org>
>>  Sent: 2014-10-03 5:35:35 PM
>>  Subject: Re: [messaging] The Simple Thing
>>
>>>  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)
>>>  *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.
>>>  *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.
>>>
>>>  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. In Version (b) Bob furthermore concludes that the 
>>>Evil Directory is evil.
>>>
>>>  The assessment is that CT-style allows only the recipient to detect 
>>>the attack, after the fact, and The Simple Thing allows the sender to 
>>>detect the attack before sending. To me this wasn't the most 
>>>intuitive summary-in both cases it's only the intended recipient 
>>>(Bob) who can be certain an attack took place and that the Evil Log 
>>>or Evil Directory has been evil.
>>>
>>>  The difference is whom you need to be "paranoid" (or just 
>>>perceptive). The Simple Thing detects attacks if the sender is 
>>>paranoid and actually insists on preemptive fingerprint checks and 
>>>CT-style detects attacks if the recipient is paranoid and has 
>>>monitoring alerts set up and actually checks them.
>>>
>>>  "Being paranoid" means slightly different things of course: setting 
>>>up monitoring vs. doing fingerprint checks. Without hard data we 
>>>can't really be sure, though intuitively it seems to me that setting 
>>>up monitoring and checking against your own recent activity is 
>>>probably easier. For one thing, in a CT-style system each key change 
>>>should only require one check (by Bob) whereas with The Simple Thing 
>>>each key change of Bob's requires all of his paranoid contacts to 
>>>initiate a fingerprint check.
>>>
>>>  The costs also seem more naturally aligned in CT-style systems: if 
>>>Bob changes keys more often he's the one that has to do more checking 
>>>of reports from monitors, whereas in The Simple Thing frequent 
>>>changes by Bob impose a burden on others.
>>>
>>>  So CT probably has some usability advantages, at the cost of 
>>>complexity and extra parties (auditors, monitors) needing to operate.
>>>
>>>  A seemingly-obvious point I haven't seen yet: it's perfectly natural 
>>>to have both systems in place. Nothing prevents layering The Simple 
>>>Thing on top of a CT-style log. Paranoid Alice can certainly check 
>>>out of band if she looks up a new key for Bob in the log and it's 
>>>different from what she's used previously. Paranoid Bob can set up 
>>>monitoring. Now you get detection if either sender or receiver is 
>>>paranoid.
>>>
>>>  On Fri, Oct 3, 2014 at 7:54 PM, Tao Effect <contact at taoeffect.com> 
>>>wrote:
>>>>
>>>>  Dear elijah,
>>>>
>>>>  On Oct 3, 2014, at 11:43 AM, elijah <elijah at riseup.net> wrote:
>>>>>
>>>>>  In the auditing-infrastructure thing, the hope is that user agents 
>>>>>will
>>>>>  be written to smartly and automatically perform the auditing. Yes, 
>>>>>it is
>>>>>  detection after the fact. The prediction is that the number of 
>>>>>people
>>>>>  running an auditing user agent will be greater than the number of
>>>>>  senders doing fingerprint verification, and that this greater 
>>>>>number
>>>>>  will provider greater deterrent against bogus key endorsements.
>>>>
>>>>
>>>>  In the CT world, auditing and monitoring are two very different 
>>>>things, and they must not be confused.
>>>>
>>>>  Auditing does not detect mis-issued certificates/keys/whatever 
>>>>before the fact, during the fact, or after the fact [1].
>>>>
>>>>  Kind regards,
>>>>  Greg Slepak
>>>>
>>>>  [1] 
>>>>https://blog.okturtles.com/2014/09/the-trouble-with-certificate-transparency/
>>>>
>>>>  --
>>>>  Please do not email me anything that you are not comfortable also 
>>>>sharing with the NSA.
>>>>
>>>>
>>>>
>>>>  _______________________________________________
>>>>  Messaging mailing list
>>>>  Messaging at moderncrypto.org
>>>>  https://moderncrypto.org/mailman/listinfo/messaging
>>>>
>>>
>>
>>  _______________________________________________
>>  Messaging mailing list
>>  Messaging at moderncrypto.org
>>  https://moderncrypto.org/mailman/listinfo/messaging