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

[Lawrence Conroy <[e-mail]>]

Hi folks,
 I entirely disagree with this suggestion to delay protocol work until after
a "full" problem statement/requirements analysis has been done.

It's the IETF, for goodness sakes, and many a proposed group hasn't even
been able to START until it's almost too late for any market due to being
buried under requirements capture and analysis and even building consensus
on terminology [Ahem - Speermint, Drinks, ...]. Also, can we avoid taking
a small and simple idea and burying it under a load of different potential
options before it even gets to be a WG -- [HIP -- sigh].
Let's not do that yet again, please.

The work so far has pretty obvious target uses (TLS, IPSEC), and expanding
this list forever is hardly in keeping with the "small bite" approach that
the IETF is supposed to prefer.

The fact that the work described in the charter is not ALL the work that is
needed to roll out this scheme should be entirely unsurprising. It's surely
not a reason to stop ANY work (apart from deep thought on the problem space).
I trust we don't require a PS-level fully worked system before a WG can begin.

In Maastricht there was quite a bit of support for this work; I do not see
a drop in the effort being applied. It seems to have momentum and people to
work on its charter tasks.
I believe that the WG should begin now, and I would trust that there can be
implementations to test out the initial proposals soon. Running code is good.
This assumes the protocol work is not slugged by being forced to wait for
everything else to be complete first -- it would be a shame if 3GPP (or the
ITU §-) were quicker at delivery that the IETF.

We're wildly agreeing that the potential of DNSSEC as an alternative trust and
validation approach for TLS/IPSEC is interesting, and I for one would like to
be able to add this as part of the toolbox I can apply soon.
Before I retire would be good.

There are bound to be some areas that are local policy -- clients might choose
one policy or another, but at the moment they don't have the choice.
This WG claims to give that choice. One can write documents until one's hand
drops off, but in the end it's up to the market.
IMHO -- give this WG a chance to DEMONSTRATE this scheme, and let's see what
falls.

all the best,
  Lawrence



On 26 Oct 2010, at 21:44, Yaron Sheffer wrote:

> I believe it is too early to form a working group for kidns.
> 
> The group has not produced a problem statement, nor is one proposed in the draft charter. While in most cases you can hide a problem statement in the first section or two of an RFC, in this case it is essential that the usage scenarios be hashed out before the technical solutions are discussed.
> 
> With respect, the technical solution from what I've seen doesn't look terribly difficult, though we can argue forever about the details. But the eventual goal of this work for some of the participants (and one which I personally support) is to provide an alternative to PKI. And the goal of this work is something that we need to socialize and have consensus on. Right now, even at the technical level the draft is ambiguous on whether DNS-based validation replaces or not the regular PKIX validation, with wording such as "a client MAY choose to trust a DNSSEC-secured certificate association".
> 
> Lastly, the group includes contributors from the CA industry, which is very good. But given that we're putting all our trust in the DNS infrastructure and procedures, I would hope to see some domain operators in the loop.
> 
> To summarize: this is important work; I support a BOF (but not a WG) in Beijing and recommend the addition of a problem statement document into the charter.
> 
> Thanks,
> 	Yaron
> 
> On 10/26/2010 07:00 PM, IESG Secretary 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 ([e-mail]) by Tuesday,
>> November 7, 2010
>> 
>> Keys In DNS (kidns)
>> -----------------------
>> Last modified: 2010-10-25
>> Current status: Proposed Working Group
>> 
>> Chairs:
>>     Warren Kumari<[e-mail]>
>>     Ondrej Sury<[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
>> 
>> 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
>> _______________________________________________
>> IETF-Announce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ietf-announce
> _______________________________________________
> keyassure mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/keyassure