[messaging] The Simple Thing

[Ximin Luo]

On 24/09/14 23:29, elijah wrote:
> * For the 2% that does give a damn, it is a lot easier (and likely more
> secure) to just put the responsibility on them (rather than the key
> owner), instead of building building a complex infrastructure just for
> this 2%.
> 

Efforts should still be made on UIs for this 2%, that reduce the cost of doing key validation. Then maybe 2% will slowly turn into 98%.

> My objection to the "simple thing" is that, if I am Bob, I eventually
> want the ability to say, "I don't care if the other party is in the 2%
> that gives a damn or not, because I care, and I would rather that people
> cannot communicate with me than for any of my communication to be
> compromised". The argument against this is that any system that
> supported this would have horrible usability, because as Bob I would be
> potentially forcing complicated key failure states on anyone who
> communicates with me, even if they have already decided they don't want
> to deal with this kind of shit.
> 

Is one-sided MITM possible? If I am Bob and I am the 2% and I validate Alice's key, and I know my *own* key, then according to my own knowledge, both keys involved in the channel are valid and there should be no MITM?

Alice does not know this of course, because she doesn't care. But this is different from your objection, where Bob's communication "is compromised". I don't think that can happen. Bob knows the communication is uncompromised, but Alice does not. As Bob, I am OK (the typical Bob should be OK) about Alice not knowing the communication is uncompromised, because I *do* know it.

> This is a good point, but it still makes me uncomfortable. In the spirit
> of the incremental key validation rules I previously posted
> (https://pad.riseup.net/p/key-validation), I feel like it should be
> possible to start with the simple thing but to also allow for the
> complex thing if both parties support it. As written, this scheme for
> incremental key validation would do the 'simple thing' in cases where
> keys do not have expiration dates.
> 

I like that document and it is very similar to something I posted a while ago [1] although my description was less eloquent than this. Many +++ for a central key/contacts manager application that does key validity inference and performs automatic validation via suitable available communications channels. (No, not GPG WoT, but something smarter, automated and pro-active, and which can reason about unverified channels too, to "build up confidence".)

X

[1] https://moderncrypto.org/mail-archive/messaging/2014/000171.html

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140924/abd8e211/attachment.sig>