DNS-based Authentication of Named Entities

The information below is for an older approved charter
Document Charter DNS-based Authentication of Named Entities WG (dane) Snapshot
Title DNS-based Authentication of Named Entities
Last updated 2010-12-10
State Approved
WG State Concluded
IESG Responsible AD Stephen Farrell
Charter Edit AD (None)
Send notices to (None)


  Specify mechanisms and techniques that allow Internet applications to
  establish cryptographically secured communications by using information
  distributed through DNSSEC for discovering and authenticating public 
  keys which are associated with a service located at a domain name.
  Problem Statement:
  Entities on the Internet are usually identified using domain names and
  forming a cryptographically secured connection to the entity requires
  the entity to authenticate its name. For instance, in HTTPS, a server
  responding to a query for <https://www.example.com> is expected to
  authenticate as "www.example.com". Security protocols such as TLS and
  IPsec accomplish this authentication by allowing an endpoint to prove
  ownership of a private key whose corresponding public key is somehow
  bound to the name being authenticated. As a pre-requisite for
  authentication, then, these protocols require a mechanism for bindings
  to be asserted between public keys and domain names.
  DNSSEC provides a mechanism for a zone operator to sign DNS
  information directly, using keys that are bound to the domain by the
  parent domain; relying parties can continue this chain up to any trust
  anchor that they accept. In this way, bindings of keys to domains are
  asserted not by external entities, but by the entities that operate the
  DNS. In addition, this technique inherently limits the scope of any
  given entity to the names in zones he controls.
  This working group will develop mechanisms for zone operators to
  present bindings between names within their control and public keys, in
  such a way that these bindings can be integrity-protected (and thus
  shown to be authentically from the zone operator) using DNSSEC and
  used as a basis for authentication in protocols that use domain names as
  identifiers. Possible starting points for these deliverables include
  draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and
  The mechanisms developed by this group will address bindings between
  domain names and keys, allowing flexibility for all key-transport
  mechanisms supported by the application protocols addressed (e.g., both
  self-signed and CA-issued certificates for use in TLS).
  The solutions specified by this working group rely upon the security of
  the DNS to provide source authentication for public keys. The decision
  whether the chain of trust provided by DNSSEC is sufficient to trust the
  key, or whether additional mechanisms are required to determine the
  acceptability of a key, is left to the entity that uses the key 
  material.  In addition to the protections afforded by DNSSEC, the 
  protocols and mechanisms designed by this working group require securing 
  the "last hop" by operating a local DNS resolver or securing the 
  connection to remote resolver - this WG will not specify new mechanisms 
  to secure that hop, but will reference existing specifications or 
  document existing methods in order to allow implementations to 
  interoperate securely.
  Initial deliverables for this working group are limited to distribution 
  of bindings between names within the zone operator's control and public 
  keys.  More general statements of policy for a domain are out of scope, 
  and new tasks in this area may only be adopted through a re-chartering.
  The group may also create documents that describe how protocol entities
  can discover and validate these bindings in the execution of specific
  applications. This work would be done in coordination with the IETF
  Working Groups responsible for the protocols.