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-­‐user’s   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.    

• • •

• • • • • •

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  

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,   the   DPF   record   would   be   stored   under       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   ICANN’s   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 |


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:  

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]      

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 |


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.    


Integer Integer


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.  





123 Mission Street | Suite 1020 | San Francisco, CA | 94105 415-378-9580 |


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]  




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.  



Is  DKIM  enabled  for  this  domain?  

  Table  3  –  WWW  Related  Entries  
Entry  Name   Value  Type  



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



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



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



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.  



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 |


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:  

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 |


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  into  her  URL  bar   2) The  browser  connects  to  using  plaintext  HTTP.   3) The  response  from  contains  an  instant  301  Redirect  to   4) The   response   from   contains   a   301   Redirect   to     as  well  as  this  HTTP  header:    
Strict-Transport-Security: max-age=15768000 ; includeSubDomains; newTLD=secure;

5) The   user’s   browser   proceeds   with   the   normal   steps   to   connect   to,   and   caches  the  redirect  in  its  local  HSTS  database.   6) The   next   time   the   user   types   into   her   URL   bar,   the   browser   automatically   rewrites  it  as  and  connects  directly.    

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.    

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 |