[keyassure] Fwd: WG Action: DNS-based Authentication of Named Entities (dane)

[Warren Kumari <[e-mail]>]

Hello everyone...

Well, it is official, we are formally a Working Group -- I'd like to start of by thanking everyone for all of their input and help getting this formed, hammering out the charter, etc.

So, as mentioned in an earlier mail, we are planning on hitting the round running -- as mentioned in a previous mail, Ondrej and myself have already asked Paul Hoffman and Jakob if they would be willing to author −00 of the protocol document (starting with the ideas from the three documents listed in the charter, augmented by the wide discussion that has happened since we submitted the charter) and they have graciously agreed to do so.

We have also asked Matt Lepinski <[e-mail]> to please serve as WG Secretary and would like to thank him for taking on this role...

Once again, thanks all -- but this is just the beginning and we're (eagerly) expecting a bunch more work from y'all :-)

W

(A quick note on the name: Unfortunately KIDNS was viewed as too close to KITTEN -- I really wanted PUPPY, but we couldn't come up with a good (reverse) acronym, and DONKEY was ruled out -- so, we have settled on (great) DANE. Please note that the charter specifies what we work on, not the name....).



Begin forwarded message:

> From: IESG Secretary <[e-mail]>
> Date: December 10, 2010 1:17:05 PM EST
> To: IETF Announcement list <[e-mail]>
> Cc: [e-mail], [e-mail], [e-mail]
> Subject: WG Action: DNS-based Authentication of Named Entities (dane) 
> 
> A new IETF working group has been formed in the Security Area.  
> For additional information, please contact the Area Directors or the WG
> Chairs.
> 
> DNS-based Authentication of Named Entities (dane)
> ---------------------------------------------------
> Current Status: Active Working Group
> 
> Chairs:
>  Warren Kumari <[e-mail]>
>  Ondrej Sury <[e-mail]>
> 
> WG Secretary:
>  Matt Lepinski <[e-mail]>
> 
> Security Area Directors:
>  Sean Turner <[e-mail]>
>  Tim Polk <[e-mail]>
> 
> Security Area Advisor:
>  Tim Polk <[e-mail]>
> 
> Mailing Lists:
>  General Discussion: [e-mail]
>  To Subscribe: https://www.ietf.org/mailman/listinfo/keyassure
>  Archive:
> http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html
> 
> Description of Working Group:
> 
> Objective:
> 
> 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
> draft-josefsson-keyassure-tls.
> 
> 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.
> 
> Goals and Milestones:
> 
> Apr 2011  First WG draft of standards-track protocol for using DNS to 
>          associate hosts with keys for TLS and DTLS
> May 2011  First WG draft of standards-track protocols for using DNS to 
>          associate hosts with IPsec
> Sep 2011  Protocol for using DNS to associate domain names with keys for 
>          TLS and DTLS to IESG
> Sep 2011  Protocols for using DNS to associate domain names with keys 
>          for IPsec to IESG
> Nov 2011  Recharter
>