Subject: Re: [keyassure] WG Review: Keys In DNS (kidns)

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 26 Oct 2010 16:56:23 -0500 (GMT-05:00)

Ted and all,

-----Original Message-----
>From: Ted Hardie <[email-masked]>
>Sent: Oct 26, 2010 1:36 PM
>To: [email-masked]
>Cc: [email-masked], [email-masked]
>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
><[email-masked]> 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 ([email-masked]) by Tuesday,
>> November 7, 2010
>>
>> Keys In DNS (kidns)
>> -----------------------
>> Last modified: 2010-10-25
>> Current status: Proposed Working Group
>>
>> Chairs:
>>    Warren Kumari <[email-masked]>
>>    Ondrej Sury <[email-masked]>
>>
>> Security Area Directors:
>>    Sean Turner <[email-masked]>
>>    Tim Polk <[email-masked]>
>>
>> Security Area Advisor:
>>    Tim Polk <[email-masked]>
>>
>> Mailing Lists:
>>    General Discussion: [email-masked]
>>    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 [email-masked]
Phone: 214-244-4827