Long Term R&D: Decentralized CA and DNS (proposal)

Roadmap
1

1. Summary

This is a motion proposal for the long-term R&D of the DFINITY Foundation, as part of the follow-up to this post: Motion Proposals on Long Term R&D Plans (Please read this post for context).

This project’s objective

The Internet Computer offers dapp developers a possibility to build and host Web dapps on the Internet Computer that are served completely end-to-end through blockchain to any browser.

To ensure end-2-end security and verifiability of such content one needs to make decentralized blockchain-based certification compatible with the built-in browser tooling and verification mechanisms. Currently, this is achieved by using additional software, service workers, certified by “Let’s Encrypt”, which is one of the centralized certificate authorities accepted by browsers.

This project aims to provide mechanisms that ensure seamless verification of the content that is served from the Internet Computer blockchain to any browser and guarantee end-2end security without additional tooling, using built-in tools only. This includes making the IC a decentralized Certificate Authority and providing a decentralized DNS on the IC.

2. Discussion lead

Maria Dubovitskaya

3. How this R&D proposal is different from previous types

Previous motion proposals have revolved around specific features and tended to have clear, finite goals that are delivered and completed. They tended to be measured in days, weeks, or months.

These motion proposals are different and are defining the long-term plan that the foundation will use, e.g., for hiring and organizational build-out. They have the following traits and patterns:

  1. Their scope is years, not weeks or months as in previous NNS motions
  2. They have a broad direction but are active areas of R&D so they do not have an obvious line of execution.
  3. They involve deep research in cryptography, networking, distributed systems, language, virtual machines, operating systems.
  4. They are meant to match the strengths of where the DFINITY foundation’s expertise is best suited.
  5. Work on these proposals will not start immediately.
  6. There will be many follow-up discussions and proposals on each topic when work is underway and smaller milestones and tasks get defined.

An example may be the R&D for “Scalability” where there will be a team investigating and improving the scalability of the IC at various stages. Different bottlenecks will surface and different goals will be met.

3. How this R&D proposal is similar to what we have seen

We want to double down on the behaviors we think have worked well. These include:

  1. Publicly identifying owners of subject areas to engage and discuss their thinking with the community
  2. Providing periodic updates to the community as things evolve, milestones reached, proposals are needed, etc…
  3. Presenting more and more R&D thinking early and openly.

This has worked well for the last 6 months so we want to repeat this pattern.

4. Next Steps

Developer forum intro posted
1-pager from the discussion lead posted
NNS Motion proposal submitted

5. What we are asking the community

  • Ask questions
  • Read 1-pager
  • Give feedback
  • Vote on the motion proposal

Frankly, we do not expect many nitty-gritty details because these are meant to address projects that go on for long time horizons.

The DFINITY foundation’s only goal is to improve the adoption of the IC so we want to sanity-check the projects we see necessary for growing the IC by having you (the ICP community) tell us what you all think of these active R&D threads we have.

6. What this means for the existing Roadmap or Projects

In terms of the current roadmap and proposals executed, those are still being worked on and have priority.

An intellectually honest way to look at this long-term R&D project is to see them as the upstream or “primordial soup” from which more baked projects emerge from. With this lens, these proposals are akin to asking, “what kind of specialties or strengths do we want to make sure DFINITY foundation has built up?”

Most (if not all) projects that the DFINITY foundation has executed or is executing are borne from long-running R&D threads. Even when community feedback tells the foundation, “we need X” or “Y does not work”, it is typically the team with the most relevant R&D area that picks up the short-term feature or project.

7 Likes
2

Please note:

Some folks gave asked if they should vote to “reject” any of the Long Term R&D projects as a way to signal prioritization. The answer is simple: “No, please, ACCEPT” :wink:

These long-term R&D projects are the DFINITY’s foundation’s thesis at R&D threads it should have across years (3 years is the number we sometimes use internally). We are asking the community to ACCEPT (pending 1-pager and more community feedback of course). Prioritization can come at a separate step.

2 Likes
3

Decentralized CA and DNS (One-pager)

Summary

Background: The Internet Computer (IC) offers dapp developers a possibility to build and host Web dapps on the Internet Computer that are served completely end-to-end from the blockchain to a browser.

To ensure end-2-end security and verifiability of such content one needs to make decentralized blockchain-based certification compatible with the built-in browser tooling and verification mechanisms. Currently this is achieved by using additional software, so called service workers, certified by “Let’s Encrypt”, which is one of the centralized certificate authorities (CA) accepted by browsers. There are also no built-in mechanisms to use custom domains for canister smart contracts running on Internet Computer.

Objective: This project aims to provide mechanisms that ensure custom domain names and seamless verification of the content that is served from the Internet Computer blockchain to any browser and guarantee end-2-end security without additional tooling, using built-in mechanisms only. This includes making the IC a decentralized Certificate Authority and providing a decentralized DNS on the IC.

Why this is important and why the DFINITY Foundation should make this a long-running R&D project

All current PKI systems used by the browsers assume centralized trusted third parties to serve as roots of trust (certificate authorities). To achieve true decentralization it is important to enable a decentralized system to act as a root of trust and interface with the current tooling to allow using it seamlessly and securely.

Becoming a decentralized CA is not just technically challenging: besides implementing cryptographic operations in a distributed fashion (for example, using threshold signatures instead of simple signatures) it also requires work and cooperation with browser manufacturers to complete the process of becoming a (root) CA supported by different browsers. The latter especially takes time and also support from the legal and compliance teams.

Key milestones & topics under this project

The project aims to achieve this goal via multiple steps (milestones):

  1. Make the Internet Computer serve as a decentralized CA
    1.1 Technical enablement:

    • Develop and implement multi-party computation protocols for TLS handshake
    • Develop and implement multi-party computation protocols for certifying the content (this includes the threshold ECDSA work that is in progress)

    1.2. Process and registration:

    • Apply to serve as a subordinate CA
    • Apply to serve as a root CA (to be able to certify any domain).

  2. Enable decentralized DNS support for canister smart contracts hosted on IC

  3. Ensure seamless content verification support for different platforms and browsers (via web or native Apps) with strong security guarantees. This includes integration with boundary nodes (see also Boundary Node project proposal).

People involved

Discussion leads: @maria @bitdivine @bjoern

Skills and Expertise necessary to accomplish this

The problems described above require the cooperation of different experts: from researchers and engineerings working on Cryptography, PKI, Networking, and Web technologies (to build the technical foundation) to specialists in Security, Compliance and Legal (to ensure that the Internet Computer can serve as a decentralized CA and DNS service).

What we are asking the community

Please review this proposal and provide us with any feedback you have regarding the boundary nodes. Please also review the other related proposals on trusted execution environments and boundary nodes. We invite you to engage in the discussion and hope it will be fruitful and useful for the IC community and for the future edge framework of the IC.

8 Likes
4

Proposal is live: Internet Computer Network Status

1 Like
5

Would the DNS service only be accessible by other canisters, or would it be capable of functioning as a drop-in replacement to existing DNS servers on end-user machines?

4 Likes
6
  1. Ensure seamless content verification support for different platforms and browsers (via web or native Apps) with strong security guarantees. This includes integration with boundary nodes (see also Boundary Node project proposal).

By content verification, do you simply refer to the security guarantees made by TLS (i.e. confidentiality, server authentication, and message integrity), or is there something beyond that?

1 Like
7

Perhaps as a stopgap we can use Rust?

Here is a cursory look at the trust_dns crate, some RFC 1035 terms and a snippet of code…

Domain name

A domain name is almost what you probably think of when you use the term domain name in your everyday language. The technical definition includes some special cases such as the root domain, which is encoded as a single dot, and domain names that need to be case insensitive.

Defined in trust_dns::domain::Name

pub struct Name {

is_fqdn: bool, // fqdn stands for fully qualified domain name.
labels: Vec<Label>,

Message

A message is a container for both requests to DNS servers (called queries ) and responses back to clients (called answers ). Messages must contain a header, but other fields are not required. A Message struct represents this and includes several Vec fields. These do not need to be wrapped in Option to represent missing values as their length can be 0.

Defined in trust_dns::domain::Name

struct Message {

header: Header,
queries: Vec<Query>,
answers: Vec<Record>,
name_servers: Vec<Record>,
additionals: Vec<Record>,
sig0: Vec<Record>, // sig0, a cryptographically signed record, verifies the
//message’s integrity. It is defined in RFC 2535.
edns: Option<Edns>, // edns indicates whether the message includes extended DNS
}

Message type

A message type identifies the message as a query or as an answer. (Queries can also be updates)

Defined in trust_dns::op::MessageType

pub enum MessageType {

Query,
Response,

}

Message ID

A number that is used for senders to link queries and answers.

u16

Resource record type

The resource record type refers to the DNS codes that you’ve probably encountered if you’ve ever configured a domain name. Of note is how trust_dns handles invalid codes. The RecordType enum contains an Unknown(u16) variant that can be used for codes that it doesn’t understand.

Defined in

trust_dns::rr::record_type::RecordType

pub enum RecordType {

A,
AAAA,
ANAME,
ANY,
/ / ...

Unknown(u16),
ZERO,

}

Query

A Query struct holds the domain name and the record type that we’re seeking the DNS details for. These traits also describe the DNS class and allow queries to distinguish between messages sent over the internet from other transport protocols.

Defined in trust_dns::op::Query

pub struct Query {

name: Name,
query_type: RecordType,
query_class: DNSClass,

}

Some sample code for constructing a DNS message in Rust…

*// A Message is a container for queries (or answers)*
let mut msg = Message::new();.
msg
*// Generates a random u16 number*
.set_id(rand::random::<u16>())
.set_message_type(MessageType::Query)
*//Multiple queries can be included in the same message*
.add_query(
*//The equivalent type for IPv6 addresses is AAAA*
    Query::query(domain_name, RecordType::A)
)

.set_op_code(OpCode::Query)
*// Requests that the DNS server asks other DNS servers if*
*// it doesn’t know the answer.*
.set_recursion_desired(true);

Scratching out the flow …
Parse command-line arguments
Build a DNS message using trust_dns types
Convert the structured data into a stream of bytes
Send those bytes across the wire
Accept response from server and decode incoming bytes.

9

Looks like decentralized/onchain DNS has already been solved https://3dns.box/

2 Likes
10

ens & whatever 3dns.box is do not solve a key problem: certificate authority & revocation.

How can a client check a pki root on chain without using the browser root of trust?

Who is managing the browser bundle root of trust? Mozilla?

E.g., most rust projects use: GitHub - rustls/webpki-roots: CA certificates for use with webpki

We need an on-chain solution. Ideally you prove your ENS / Identity ↔ ip address ownership by posting your identity credential as a TXT record on DNS, and DNS capable clients can check. For clients that can’t use DNS ( smart contracts, something like a Poseidon hash of your TXT record, retrieved with something like tlsnotary.org, could be verified on chain.

Obv it’s a bit more complex but we need something!

1 Like