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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Messaging mailing list
[email protected]
https://moderncrypto.org/mailman/listinfo/messaging

Reply via email to