Engineering Insights is an ongoing blog series that gives a behind-the-scenes look into the technical challenges, lessons and advances that help our customers protect people and defend data every day. Each post is a firsthand account by one of our engineers about the process that led up to a Proofpoint innovation.
In this blog post, we discuss the Domain Relationship Policy Framework (DRPF)—an effort that has been years in the making at Proofpoint. The DRPF is a simple method that is used to identify verifiably authorized relationships between arbitrary domains. We create a flexible way to publish policies. These policies can also describe complex domain relationships.
The details for this new model require in-depth community discussions. These conversations will help us collectively steer the DRPF toward becoming a fully interoperable standard. We are now in the early proposal stage for the DRPF, and we are starting to engage more with the broader community. This post provides a glimpse down the road leading to standardization for the DRPF.
Why Proofpoint developed DRPF
To shine a light on why Proofpoint was inspired to develop the DRPF in the first place, let’s consider the thinking of the initial designers of the Domain Name System (DNS). They assumed that subdomains would inherit the administrative control of their parent domains. And by extension, this should apply to all subsequent subdomains down the line.
At the time, this was reasonable to assume. Most early domains and their subdomains operated in much the same way. For example, “university.edu” directly operated and controlled the administrative policies for subdomains such as “lab.university.edu” which flowed down to “project.lab.university.edu.”
Since the mid-1980s, when DNS was widely deployed, there has been a growing trend of delegating subdomains to third parties. This reflects a breakdown of the hierarchical model of cascading policies. To see how this works, imagine that a business uses “company.com” as a domain. That business might delegate “marketing.company.com” to a third-party marketing agency. The subdomain must inherit some policies, while the subdomain administrator may apply other policies that don’t apply to the parent domain.
Notably, there is no mechanism yet for a domain to declare a relationship with another seemingly independent domain. Consider a parent company that operates multiple distinct brands. The company with a single set of policies may want them applied not only to “company.com” (and all of its subdomains). It may also want them applied to its brand domains “brand.com” and “anotherbrand.com.”
It gets even more complex when any of the brand domains delegate various subdomains to other third parties. So, say some of them are delegated to marketing or API support. Each will potentially be governed by a mix of administrative policies.
In this context, “policies” refers to published guidance that is used when these subdomains interact with the domain. Policies might be for information only. Or they might provide details that are required to use services that the domain operates. Most policies will be static (or appear so to the retrieving parties). But it is possible to imagine that they could contain directives akin to smart contracts in distributed ledgers.
3 Design characteristics that define DRPF
The goal of the DRPF is to make deployment and adoption easier while making it flexible for future use cases. In many prior proposals, complex requirements bogged down efforts to get rid of administrative boundaries between and across disparate domains. Our work should be immediately useful with minimal effort and be able to support a wide array of ever-expanding use cases.
In its simplest form, three design characteristics define the DRPF:
- A domain administrator publishes a policy assertion record for the domain so that a relying party can discover and retrieve it.
- The discovered policy assertion directs the relying party to where they can find an accompanying policy document.
- Beyond a set of simple policy primitives published within the assertion record itself, the syntax and semantics to be used in the policy document can be defined separately by those interested in specific use cases that the framework enables.
Essentially, our work defines a standardized way to publish policies that describe domain relationships. And it makes it easy to discover those policies. Beyond that, the policies are flexible. They can be defined as new use cases emerge. This approach avoids the complexity of trying to include all possible policy models into one specification.
An overview of the DRPF model in its simplest form.
The only requirement is that the policy assertion must be published in an easily discoverable location. It must also point to where the policy document can be found. This supports easy adoption, especially for simplistic use cases. It allows for maximum flexibility, too, which is needed to support complex or otherwise esoteric and heretofore unknown use cases.
Note: Simplicity masks the powerful ability of DRPF to support more complex use cases. So, in the next section, we will take a simple approach to start. And then we will show you how it can be extended as needed.
A simple use case with many potential applications
Without getting too deep into the technical weeds, another key requirement of DRPF is the ability to verify the authenticity of policies that apply across disparate domains. To address this issue, the DRPF introduces a bidirectional verification mechanism. Digital signature mechanisms—and the utility of using DNSSEC—are set aside. Instead, cross-domain policies can be confirmed using pointers that confirm the relationships.
The simplest—and likely, the most common—way to validate that policies between related domains are authorized is for both of the domains to confirm the relationship. For that to happen, the administrator of each domain needs to publish a policy that points to a policy that the other domain has published. The policy includes the necessary directives to confirm the directed relationship according to its status in the relationship.
For example, say that a company registers “inactive.com” and then parks it because it wants to control policies that apply to the domain under its primary “company.com” domain. Let’s assume in this case that the policy directive “parked” has been defined in the specification such that it conveys meaning. The administrator then publishes a policy to “inactive.com” that says:
-
“childof:company.com; status:parked;”
After the relying party retrieves the policy, they can find the related policy published at “company.com” and parse it for the correlated declaration:
-
“parentof:inactive.com; child:status:parked;”
Many additional layers of related policies may exist. But this simple, approach is all that is needed to confirm the “parent::child” relationship between the domains, providing guidance for the application of policies.
Similarly, if there’s no confirmation, then it’s a strong signal to relying parties that something may be amiss. For instance, let’s imagine a scenario where “unrelated.com” publishes a policy that indicates a relationship with “company.com”—but no confirming policy is found. In this case, the relying party can then modify its actions and treat the purported relationship as suspect.
There is a lot more detail behind this simple use case. But the interest that Proofpoint has already seen in this model has been encouraging. In fact, with each interaction across the community, we’re learning about additional use cases the framework could address like:
- The publication of simple corporate information, like related brands, customer service information and abuse reporting addresses
- Third-party authorization management, like supply chain and vendor policies
- Regulatory compliance documentation
A day rarely goes by when we don’t consider a new use case to see if the model supports it—without adding undue complexity.
Extending beyond simple use cases
Most modern organizations rely on various third-party services to streamline their operations and make the user experience better. These collaborations span diverse domains, from payment processors to analytics tools. This makes it nearly impossible to keep all interactions in a single domain.
The ability to publish in-depth DRPF policies can unravel the intricate domain dependencies and reveal intent and expectation when interacting with the domains. This can further help the internet community be more knowledgeable and secure.
When considering how the DRPF applies to your domains, many practical questions come up, like:
- Can it support complex interactions like a three-way interaction between a company, a payment provider and a commerce site?
- Are there clear definitions of reasonable expectations for dynamic policies? How can their directives, including expirations, be enforced as the policies evolve?
- Is there a provision for companies with many-to-many relationships to perform roll-ups based on secondary policy relationships?
The answer to each is a resounding yes! The real question is: what key features and use cases need to be defined first, paving the way for later work to follow? If these are some of your questions, we welcome you to join the conversation and help define the DRPF framework.
Consider joining the conversation about DRPF
There is still a long way to go before DRPF’s full potential can be realized. But we’re nearing the point where we’re ready to support early interoperability trials. It is exciting to see the DRPF taking shape across the ecosystem as Proofpoint developers evaluate security models that would use the additional domain-published signals the framework enables.
If you are interested in the technical details of DRPF and are excited about the value that the framework can bring to your business, please consider joining the conversation as the community collaborates on development. Let your Proofpoint account manager know about your interest in DRPF, and we’ll be in touch. Let’s change the world together!
Join the team
At Proofpoint, our people—and the diversity of their lived experiences and backgrounds—are the driving force behind our success. We have a passion for protecting people, data and brands from today’s advanced threats and compliance risks.
We hire the best people in the business to:
- Build and enhance our proven security platform
- Blend innovation and speed in a constantly evolving cloud architecture
- Analyze new threats and offer deep insight through data-driven intelligence
- Collaborate with our customers to help solve their toughest cybersecurity challenges
If you’re interested in learning more about career opportunities at Proofpoint, visit the careers page.
About the author
J. Trent Adams is a technologist, strategist and futurist focused on online identity, privacy and security. His strengths are his breadth of experience and ability to effectively communicate as easily with engineers as heads of state. He built one of the first 500 websites, was a technical adviser on identity technologies at ISOC, and helped develop an acronym soup of technologies such as OpenID, OAuth, CSP, DMARC, FIDO and ARC.
Meanwhile, Adams was in “Star Wars: The Force Awakens,” and the producer of the feature film “Norman.” He also earned three Super Bowl rings as the chief innovator for the New England Patriots. Adams is the executive producer for the space exploration media company Cosmic Perspective and is on the boards of the Analog Astronaut Foundation and the Western States Cancer Research NCORP.