[messaging] PKI is dead

[U.Mutlu]

U.Mutlu wrote, On 01/24/2015 03:00 AM:
> Tony Arcieri wrote, On 01/24/2015 12:01 AM:
>> On Fri, Jan 23, 2015 at 1:57 AM, U.Mutlu <for-gmane at mutluit.com> 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.
>
> They are MITM safe. Basically one needs just DH + Key Authentication,
> for example H(DHkey,H(p)), whereby on server only H(p) is known and stored.
> This authenticates not only the client to the server, but implicitly
> also the server to the client, under the condition that the userDB
> on the server is secured against theft.

And of course using theft-protection of the userDB also
on the client (ie. for non-interactive logins, for example
of an email-client to the email-server).

The theft-protection is IMO easy to do: just encode the userDB
with some unique systemIds, like HW serial numbers...
On a different system the userDB is useless.
Of course user (and also the server admin) must have the ability
to convert the userDB to be used on new hardware. For that,
again a password is needed, for example of the admin who
administers the userDB.

So, this is a safe & secure method.


> And in my draft solution this is assured. Then we can forget about PKI wholly.
>
>> 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.
>
> Nope, exactly the opposite is true: one must use PAKE instead of PKI.
> Nothing can be secure if intermediary parties are involved, as is the case
> with PKI.
>
> cu
> Uenal