Professional Documents
Culture Documents
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
STLS
Integer
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
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
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
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.
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