DOMAIN

POLICY FRAMEWORK (DPF) INITIAL SPECIFICATION

Version 1.3 Updated May 11th, 2012 The Domain Policy Framework (DPF) is intended to be the primary mechanism by which high- security domains communicate the policies of various subdomains to the end-users client software. DPF will utilize the DNS system to publish trustworthy information about high security domains, and while HTTP and SMTP are intended to be the first protocols targeted for DPF the framework should be extensible enough to support future applications.
R EQUIREMENTS

Compatible with relevant DNS RFCs Human readable syntax High-performance in real-world use o Cacheable o Able to be side-loaded during initial DNS request o Uses smallest possible record size Compatible with DMARC for specifying mail source verification Deployment by registries should not require an ICANN RSTEP request Policy is controlled by the registry, not (directly) by the domain holder Compatible with DNSSEC and NSEC3 Robust in likely scenarios of DNSSEC failures Expansible without breaking backwards compatibility or requiring multiple records of multiple versions

ARCHITECTURE
DPF records will be stored in new, reserved zones under the control of participating TLDs. For a domain of pattern domain.tld, the domain policy would be stored as a TXT record for domain._policy.tld. For the example domain of www.bank.secure, the DPF record would be stored under www.bank._policy.secure. A DPF aware client would parse the URI and lookup the TLD in its built in base DPF database (discussed below). Any TLD with an entry would cause the client to make two parallel DNS requests, one for the host and one for the policy. The use of this structure should insure that DPF TXT records are appropriately cached throughout the DNS system in parallel to their associated host records. ICANN restricts the placement of extra records in gTLD zone files. The use of the _policy second- level-domain allows for the deployment of DPF without ICANNs permission. It also encourages TLD registries to use alternate DNS secondaries to publish the _policy zone, eliminating any load or stability risk to the TLD that could be posed by DPF.

123 Mission Street | Suite 1020 | San Francisco, CA | 94105 415-378-9580 | info@domainpolicy.org

SYNTAX
The DPF syntax is similar to the syntax of DKIM. A properly formatted DPF record will contain a list of name value pairs bonded by the ASCII = sign. The pairs will be separated by semi-colons with an optional training whitespace. For example, the content of the TXT record could look like this:
name1=value1;name2=value2; name3=value3;

Note the optional space between the second and third pairs, and the semi-colon behind the final pair. All of the characters in the name fields and the separating characters will be encoded as 7-bit ASCII. Except for the organization identification field, all of the characters in the value field will be 7-bit ASCII. Interpretation of all fields should be cases insensitive, although the case of characters in free text fields should be honored in situations where the value is displayed to a user. The pairs can be in any order with the exception of the initial pair, and the implementation of any tokenizing algorithm should be insensitive to the order of values. The DPF record will always begin with a version field, like so:
DPFv=1

All names will be comprised of up to eight consecutive alphanumeric characters. Values can fall into four types: Booleans: Encoded as a 1 for TRUE and 0 for FALSE. No other values are valid in a Boolean. Integers: A 32bit unsigned integer value between 0 and 2^32-1, expressed in BASE10 using ASCII Arabic numerals. BASE64 Encoded: Free Text Fields: Free text delimited by ASCII double quote characters. This text field can contain upper-case alphabetical, lower-case alphabetical and numeric characters. Special characters allowed include space and underscore. [ed. Need an I18N solution here, perhaps using BASE64]

DPF ENTRIES
A name-value pair where the value is of the Boolean or Integer type is also known as a DPF entry. The complete list of DPF entries published by a domain is called a DPF policy. Each DPF entry should correspond to a single security action that can be taken by a DPF client. DPF entries should generally stand-alone and not require context from other entries to aid interpretation.

123 Mission Street | Suite 1020 | San Francisco, CA | 94105 415-378-9580 | info@domainpolicy.org

Entries could exist for many types of protocols, and such entries can be mixed together in shared policies. Clients should ignore any entries that they do not understand, and continue to implement the entries they do understand. DPF versions will be iterative, and the meaning of entry names assigned in previous versions should not be modified by subsequent versions. Most entries should be encoded as Booleans or Integers. Integer entries should increase in value as the expected security benefit increases. In situations where future intermediate values may be necessary, it is appropriate to reserve values for future use. Boolean TRUE values should be more secure than FALSE values. Table 1 Network and Identity Entries
Entry Name Value Type Description DPF version. Level of DNSSEC verification required to connect to a host in this domain. This value will have the most use as a base entry included in a DPF client. Examples DPFv=1 : DPF version 1 DNSSEC=0 : Zone not signed, allow for DPF updates using unsigned records. DNSSEC=1 : Zone is signed. Upon failure of DNSSEC verification, retry with built in resolver. Allow for insecure DPF and allow connection to proceed. DNSSEC=2 : Zone is signed, attempt to re-request. Do not allow for insecure DPF, allow for connection to proceed. DNSSEC=3 : Zone is signed, attempt to re-request. Do not allow for insecure DPF, do not allow for connection after DNSSEC failure. ORG=Big Bank N.A. ORGV=0 : No verification performed. Self-identified. ORGV=2 : Personal identification of a individual ORGV=5 : Strong enterprise verification, equivalent or better than Extended Validation Certificates. CTL= : Use built-in CA list CTL=SHA256:VH58GDSF : Restrict certificate validation to chains ending in this root.

DPFV DNSSEC

Integer Integer

ORG ORGV

Text Integer

A text field containing the verified identity of the domain owner. This will need to support I18N and alternate character sets. The level of verification performed by the registry on the organizations identity. Higher values indicate a greater level of verification. This value should be surfaced by the DPF client to the end- user via some UX mechanism. Detailed standards for this metric will need to be set. A certificate trust list comprised of comma- separated entries of BASE64 encoded hashes of trusted certificate authorities to sign certificates in this domain. The hash should be proceeded by a hash type, such as SHA1, MD5 or SHA256.

CTL

Text

123 Mission Street | Suite 1020 | San Francisco, CA | 94105 415-378-9580 | info@domainpolicy.org

Table 2 Email Related Entries

Entry Name Value Type Description Type of TLS protection provided at the mail exchanger Examples STLS=0 : No TLS required STLS=1 : STARTTLS supported on normal SMTP Port STLS=2 : Wrapped SMTPS available on port XXX STLSV=12 : TLS 1.2 minimum NOEURI=0 : URIs are allowed NOEURI=1 : URIs are not allowed, reject messages containing URIs ESIG= : No signatures expected ESIG=SMIME3 : Expect mail signed with SMIME v3 (RFC 2663) ESIG=OPGP : Expect mail signed with OpenPGP (RFC 4880) DKIM=1 : Require DKIM on all mail received from this domain. [ed. Lots of thinking needed on DMARC compat]

STLS

Integer

STLSV NOEURI ESIG

Integer Boolean Text

Minimum required TLS version for SMTPS Are valid URIs allowed in emails from this domain? Expected email signature algorithm for messages received from this domain.

DKIM

Boolean

Is DKIM enabled for this domain?

Table 3 WWW Related Entries

Entry Name Value Type

HTLS

Integer

Description Minimum required TLS version for initial HTTP connection. 0 means no TLS required.

INCLD

Boolean

Are pages in this domain restricted from including content from non-TLS protected HTTP endpoints?

TLSEV

Integer

Is an extended validation certificate required on servers in this domain?

3CKIES

Boolean

Are third party cookies allowed to be set by sites running on this domain? A text string containing plugins that are not allowed to run on this domain.

NOPLGINS

Text

Examples HTLSv=0 : No TLS required, connect using HTTP. HTLSv=13 : TLS 1.3 required. Initially connect using HTTPS, reject all versions of TLS less than 1.3 INCLD=0 : Normal include policy INCLD=1 : Non-executable includes allowed over HTTP, such as images INCLD=2 : All includes must be served over HTTPS INCLD=3 : All includes must be served from this TLD INCLD=4 : All includes must be served from this exact domain TLSEV=0 : No requirement for EV certificate. TLSEV=1 : EV certificate or DNSSEC DANE published key TLSEV=2 : EV certificate always required 3CKIES=0 : Normal third-party cookie policy 3CKIES=1 : Do not allow third-party cookies. NOPLGINS= : Normal plugin policy NOPLGINS=FLASH;SILVERLIGHT;JAVA : No Flash, Silverlight or Java on this site NOPLGINS=ALL : No browser plugins allowed.

123 Mission Street | Suite 1020 | San Francisco, CA | 94105 415-378-9580 | info@domainpolicy.org

BASE AND RESULTANT POLICIES

The delivery of a valid DPF policy is dependent on the integrity of DNS. In situations where the DPF is intentionally blocked by an attacker, the DPF record is modified, or where there is an inadvertent failure of DNSSEC, there needs to be a mechanism that insures that the end-user is still able to connect securely to the requested domain. This can be implemented as a base policy built into the DPF client. Each domain registry participating in the DPF can publish, out of band, the minimal requirements of their gTLD. For example, such a policy might look like this:
DPFv=1;HTLS=12;DNSSEC=2;STLS=1

In situations where a client is not able to receive or validate a DPF record per its stored policy, it should fall back to base policy and act accordingly. If the client receives a validated DPF record it will need to calculate the resultant policy. The use of monotonically increasing values in order of security makes such a calculation much simpler; the larger of the two values is used. Ex:
Base Policy: Received Policy: Resultant Policy: DPFv=1;HTLS=12;DNSSEC=2;STLS=1; DPFv=2;HTLS=13;STLS=0; DPFv=2;HTLS=13;DNSSEC=2;STLS=1;

TLD registries can also publish a blank policy using only the DPFv entry. This will provide maximum compatibility and allow for DPF records to be published by the incumbent TLDs.

123 Mission Street | Suite 1020 | San Francisco, CA | 94105 415-378-9580 | info@domainpolicy.org

ADDENDUM TO HSTS
HTTP Strict Transport Security (HSTS) in an Internet Draft standard supported by most modern browsers. It is used by security sensitive sites to signal to user-agents their desire to only be accessed using HTTPS. We would like to extend HSTS to perform an additional function: to allow for permanent redirects from an old gTLD to a new one. Here is an example flow: 1) A user types www.bank.com into her URL bar 2) The browser connects to www.bank.com using plaintext HTTP. 3) The response from bank.com contains an instant 301 Redirect to https://www.bank.com 4) The response from https://www.bank.com contains a 301 Redirect to https://www.bank.secure as well as this HTTP header:
Strict-Transport-Security: max-age=15768000 ; includeSubDomains; newTLD=secure;

5) The users browser proceeds with the normal steps to connect to www.bank.secure, and caches the redirect in its local HSTS database. 6) The next time the user types www.bank.com into her URL bar, the browser automatically rewrites it as https://www.bank.secure and connects directly.

AREAS FOR WORK

1. DPF rules for SSH, SFTP, FTP, etc 2. Need lots of study into DPF-DMARC interop 3. Need lots of study into DPF-DANE interop. DPF + DANE should allow for all of the functionality of EV certs. 4. Can we organize DPF namespace to better group rules? 5. Will DPF need to be split over multiple TXT records? Do we need a linking protocol? 6. We need a mechanism for reporting exceptions to the registry. Perhaps a one-time DNS request that encodes the exception details? This might be better than a heavy-duty web service.

VERSION HISTORY
1.0 First draft circulated to DPWG founding members 1.1 Updated with small changes, added CTL entry 1.2 Fixed typos 1.3 Added more areas for work

123 Mission Street | Suite 1020 | San Francisco, CA | 94105 415-378-9580 | info@domainpolicy.org