Ted and all, -----Original Message----- >From: Ted Hardie <ted.ietf@xxxxxxxxx> >Sent: Oct 26, 2010 1:36 PM >To: iesg@xxxxxxxx >Cc: keyassure@xxxxxxxx, ietf@xxxxxxxx >Subject: Re: [keyassure] WG Review: Keys In DNS (kidns) > >Howdy, > >The charter below has the following text: > >"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." > >The "may" in that statement and the ordering involved throw up a tiny >red flag in my head that says "Are we building a technology and then >looking for customers, rather than asking customers what technology >to build"? (With the parallel that "customers" here are the "protocol entities" >which would discover and use these bindings.) > >The answer appears to be "The customers are TLS and IPSEC". That >seems to me a big enough job for a first go-round. I would personally >suggest re-chartering to include other potential using protocols when >they have been identified, with specific coordination targets at that time >Some protocols developed outside the IETF might also want to use >this method of binding key materials, for example, and the WG coordination >for those might extend beyond IETF WGs. I think you need to add DNSSEC to the customers list as well as browser vendors/developers, IxP's and DNS providers. Just my .2 cents... > >Just my two cents, > >regards, > >Ted > > > >On Tue, Oct 26, 2010 at 10:00 AM, IESG Secretary ><iesg-secretary@xxxxxxxx> wrote: >> A new IETF working group has been proposed in the Security Area. ÂThe IESG >> has not made any determination as yet. The following draft charter was >> submitted, and is provided for informational purposes only. Please send >> your comments to the IESG mailing list (iesg@xxxxxxxx) by Tuesday, >> November 7, 2010 >> >> Keys In DNS (kidns) >> ----------------------- >> Last modified: 2010-10-25 >> Current status: Proposed Working Group >> >> Chairs: >> Â ÂWarren Kumari <warren@xxxxxxxxxx> >> Â ÂOndrej Sury <ondrej.sury@xxxxxx> >> >> Security Area Directors: >> Â ÂSean Turner <turners@xxxxxxxx> >> Â ÂTim Polk <tim.polk@xxxxxxxx> >> >> Security Area Advisor: >> Â ÂTim Polk <tim.polk@xxxxxxxx> >> >> Mailing Lists: >> Â ÂGeneral Discussion: keyassure@xxxxxxxx >> Â ÂTo Subscribe: Â Â Â https://www.ietf.org/mailman/listinfo/keyassure >> Â ÂArchive: >> http://www.ietf.org/mail-archive/web/keyassure/current/maillist.html >> >> Objective: >> Specify mechanisms and techniques that allow Internet applications to >> establish cryptographically secured communications by using information >> distributed through the DNS and authenticated using DNSSEC to obtain >> 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 domain 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 domain 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 domain 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 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. >> >> Milestones: >> Dec 2010 ÂFirst WG draft of standards-track protocol for using DNS to >> Â Â Â Â Âassociate hosts with keys for TLS and DTLS >> Jan 2011 ÂFirst WG draft of standards-track protocols for using DNS to >> Â Â Â Â Âassociate hosts with IPsec >> Jun 2011 ÂProtocol for using DNS to associate domain names with keys >> Â Â Â Â Âfor TLS and DTLS to IESG >> Aug 2011 ÂProtocols for using DNS to associate domain names with keys >> Â Â Â Â Âfor IPsec to IESG >> Aug 2011 ÂRecharter Regards, Jeffrey A. Williams "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@xxxxxxxxxxxxx Phone: 214-244-4827 _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf