I echo Trevor's comments, it's important to directly link PKI to e2e (and to mention how this conversation would be different from the ones that have already taken place multiple times on this list on the same topic).
At the same time, it should be acknowledged that PKI itself does have direct
relevancy to end-to-end secure messaging in terms of ease-of-use, as well as
the inherent security improvements that come from said ease-of-use improvements.
I am referring to:
1. Manual fingerprints verification (which users must learn to do properly)
2. Managing keys and updating them ("TheRightKey" problem)
That is why I've been pushing a "One Pin To Rule Them All" approach with
DNSChain [1], where fingerprint verification only needs to happen one time,
after which all end-to-end messaging apps benefit in that they no longer
require fingerprint verification.
At the same time a rather good competing proposal to DNSChain has surfaced that
preserves many of the same properties, but at the expense of being far more
difficult and challenging to implement, and that is full-security thin clients
for blockchains like Namecoin and others.
I think both approaches are good, and ultimately I would even favor
full-security thin clients, especially to blockchains with stronger/better
consensus mechanisms than Namecoin.
Until full-security thin-clients ("SPV+", "Ultimate blockchain compression",
etc.) come about, DNSChain provides a workable alternative, IMO.
Cheers,
Greg Slepak
[1]
https://github.com/okTurtles/dnschain/blob/master/docs/What-is-it.md#MITMProof
--
Please do not email me anything that you are not comfortable also sharing with
the NSA.
On Jan 23, 2015, at 3:05 PM, Trevor Perrin <[email protected]> wrote:
> Hi,
>
> Are we just discussing website login and Web PKI here?
>
> If there's no direct connection to end-to-end secure messaging, could
> people discuss this elsewhere?
>
> Trevor
>
>
> On Fri, Jan 23, 2015 at 1:01 PM, Tony Arcieri <[email protected]> wrote:
>> On Fri, Jan 23, 2015 at 1:57 AM, U.Mutlu <[email protected]> wrote:
>>>
>>> Back to the roots: hashed pw over MITM-safe sessions (SRP, SPEKE etc, ie.
>>> PAKE).
>>
>>
>> These aren't MITM safe. They're TOFU. They have no way to authenticate the
>> server.
>>
>> When you enroll a PAKE account, if you're talking to a MITM server, you're
>> toast. The MITM can then enroll with the real service on your behalf and
>> transparently proxy everything through, except the MITM will have the real
>> credentials, and your credentials will only work with the MITM.
>>
>> Also: passwords suck and need to go away.
>>
>> --
>> Tony Arcieri
>>
>> _______________________________________________
>> Messaging mailing list
>> [email protected]
>> https://moderncrypto.org/mailman/listinfo/messaging
>>
> _______________________________________________
> Messaging mailing list
> [email protected]
> https://moderncrypto.org/mailman/listinfo/messaging
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
