DPKI Implementation to prevent MITM attacks on HTTPS

[taoeffect]

Define You:

• "Vision Thing™"
• Infosec background

Is your feature request related to a problem? Please describe.

The problem is described in depth here: https://okturtles.org/dpki/

Summary: HTTPS is insecure because it is fairly easy to conduct a MITM attack on it.

Describe the solution you'd like...

Solution is DPKI: https://okturtles.org/dpki/

And I'll give a very specific recommendation below.

Describe alternatives you've considered?

• I've considered "pet names"
• I've considered "IPNS"
• I've considered "Certificate Transparency" and "CONIKS"

Approach to be followed (optional):

1. At least two decentralized consensus namespaces are needed (blockchains). Can start with one, but for full decentralization this approach works best with at least two (e.g. Namecoin and HNS).
2. For each blockchain, one of two approaches works:

How to do DPKI for a blockchain

1. Thin client
2. Consensus among pinned resolvers

Thin client approach

Each blockchain may have its own code for doing client-side DNS-style resolution using a thin-client (sometimes referred to as a "light client"). This approach is preferable if it is available.

Pros:

• If implemented correctly, is more secure
• Allows direct resolution on a blockchain network without trusted intermediaries
• The opposite of the "cons" list of "Consensus among pinned resolvers"

Cons:

• Is more complicated for blockchains to implement
• Requires custom code for each blockchain, and is therefore not a generalized approach that works with different blockchains

Consensus among pinned resolvers

Each blockchain may have public nodes run by trusted organizations or individuals or institutions.

The browser can then be shipped with a pre-built list of such nodes, along with the public key fingerprint that is used to verify the connection to that trusted node ("key pinning").

Then, when a query for a domain is made, the browser would randomly pick at least two of these nodes and query them. If they agree on the same value (the term "value" here refers to the public key fingerprint of the website we're trying to connect to and is the same "value" that the "thin client" approach would return) it would use that value to secure the connection to the website we're trying to visit. If they disagree, a random third resolver is selected and then we check for a quorum consensus (i.e. this would be 2 out of 3 resolvers agreeing). If we have a quorum we use that value, if not, we randomly select another resolver and so and so forth until we get a quorum for the value. If no quorum is reached by the time we've randomly queried say 6 resolvers, we display an error to the user.

Pros:

• This approach can be implemented much more easily than the thin client
• This approach does not require blockchains to implement a thin client
• This approach is simple and works with any blockchain

Cons:

• It requires maintaining a trusted list of resolvers for every supported blockchain
• The burden is then placed on the browser to make sure that the pinned public keys for each of those resolvers is up-to-date for each trusted resolver

Additional context

https://okturtles.org/dpki/