Subject: [keyassure] Participation / charter discussions...

From: Warren Kumari <[email-masked]>
Date: Wed, 22 Sep 2010 09:36:17 -0400

While I really  the passion and enthusiasm being displayed I am a bit concerned that some of the less vocal contingent might not be being heard...

It is *very* easy to filter a mailing list into a folder and get behind -- once there are a couple of hundred unread messages sitting there it becomes very difficult to dig oneself out from under the mound.

Also, some folk express themselves in a more reserved fashion and I want to make sure that we are hearing everyone's viewpoint, so...

I'm encouraging everyone to make sure that, if you have views on the charter (and other things), we have heard what you have to say (even if that is "Help, too much mail!").

W

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 22 Sep 2010 10:55:56 -0400

I'm good with the charter as is.
--Richard

On Sep 22, 2010, at 9:36 AM, Warren Kumari wrote:

> While I really  the passion and enthusiasm being displayed I am a  
> bit concerned that some of the less vocal contingent might not be  
> being heard...
>
> It is *very* easy to filter a mailing list into a folder and get  
> behind -- once there are a couple of hundred unread messages sitting  
> there it becomes very difficult to dig oneself out from under the  
> mound.
>
> Also, some folk express themselves in a more reserved fashion and I  
> want to make sure that we are hearing everyone's viewpoint, so...
>
> I'm encouraging everyone to make sure that, if you have views on the  
> charter (and other things), we have heard what you have to say (even  
> if that is "Help, too much mail!").
>
> W
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Sep 2010 08:26:22 -0700

>I'm good with the charter as is.

Me too. If the potentially-sponsoring AD wants modifications, we'll know when he tells us.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Sep 2010 11:42:38 -0400

The Security AD is only going to be able to comment on the policy/signer
restriction issue if he is aware that it is being contemplated.

I do not think the current charter makes that clear. I suggest adding the
following:

The group will consider means of using DNS secured records to express the
following types of assertion:

* Key Assurance
* Trust Restrictions
* Security Policy

And add the draft Brian and I wrote on this to the list of input documents.
http://tools.ietf.org/html/draft-hallambaker-esrv-00

I think that it is also necessary for Paul and Co to rewrite their draft so
that the intention to express trust restrictions is stated clearly in the
abstract and introduction.

-- 
Website: http://hallambaker.com/

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 22 Sep 2010 13:28:19 -0400

> if that is "Help, too much mail!").

I think I already said that once, but I'll say it again.  I have no
idea where the potential WG stands (and I expect I'll be too busy from
now until Beijing to try to figure it out, given that some
participants think the request to moderate themselves is unreasonable).

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Sep 2010 10:57:20 -0700

>participants think the request to moderate themselves is unreasonable).

There is a proposed charter with problem statement and milestones at <http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure>. There are a few threads from the past day on whether to modify that proposed charter.

--Paul Hoffman, Director
--VPN Consortium

---

From: John Gilmore <[email-masked]>
Date: Wed, 22 Sep 2010 14:30:30 -0700

> if that is "Help, too much mail!").

Thank you, Warren.

I think the charter both says too much, says too little, and doesn't
say it simply enough.  It confuses protocols and applications; IETF
standardizes protocols.  It doesn't discuss threat models, which are
prerequisite for solving a security problem.  Here is a rewrite by me
for the group's consideration.

Gilmore's revised charter:

Objective:

Specify standards-track protocols for using DNSSEC to establish
wide area cryptographically secured communications.

Problem Statement:

DNSSEC enables the operator of a domain name to sign their domain
information so that it can be authenticated, particularly via
recursive authentication to public keys associated with the DNS root
domain.  However, it provides no standard way for non-DNS protocols to
use this authentic information to bootstrap authentication or
encryption in their own protocols (beyond authenticating the IP
addresses and other DNS records associated with a domain name).
Existing protocols such as HTTPS, SSH, or IPSEC currently bootstrap
their authentication via an ad-hoc list of keys and attributes from
application vendors and third party Certificate Authorities, or via a
hand-built list validated one entry at a time by querying naive end
users.  When deployed worldwide, these methods are now known to
provide neither reliable legal assurance, nor practical technical
assurance, of authenticity.

This working group will define protocols for domain operators,
registrars, and registries to publish bindings between domain names
and public keys, in ways that can provide enforceable legal
responsibility for breaches.  It will also define protocols for
securely retrieving those authenticated keys and applying them to
bootstrap protocol-specific authentication and/or encryption in
existing and new Internet protocols such as HTTPS, SSH and IPSEC.  It
will document real and anticipated threat models, and explain how its
resulting protocols alleviate those threats.  This work will be done
in coordination with the IETF Working Groups responsible for the
protocols whose authentication we are improving.

Possible starting points for these deliverables include
draft-hallambaker-certhash, draft-hoffman-keys-linkage-from-dns, and
draft-josefsson-keyassure-tls.

	John Gilmore

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Sep 2010 12:56:23 +0100

> There is a proposed charter with problem statement and milestones at <http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure>. There are a few threads from the past day on whether to modify that p…

I'm not up to date on suggested changes from recent mails (if there
was any agreement on those - hard to tell;-) but here's what I think
of the text currently at that URL. The current text is ok-ish, but
needs work IMO.

- I'm not sure if its ok to be silent on the "putting policy stuff
with public keys in the DNS" issue. It might be, or might not be,
depending on what people want. I'd expect that this'd be controversial
within a WG, so if it were possible to get it agreed in the charter,
then that'd be preferable. However, it might be that it just has to
be debated in a WG.

- The objective part doesn't say anything about public keys. I assume
there's no intent to work on ways to use symmetric keying material, so
it might be worth saying "public keys" rather than "cryptographic
material." However this is clarified later on so its maybe a nit.

- s/identified by domain names/identified using domain names/ since
many forms of identifier have more than just the domain name

- s/may also create documents/may also create informational
documents/ and add that if any such documents should be BCPs
or on the standards-track then the group should re-charter first.
Without that, there could be a danger of conflict between this
group and another group that owns the protocol in question, so
giving the wider community a chance to vet such proposals seems
like a reasonable idea to me.

- I don't see why the milestones say "hosts" rather than domain
names and I think "domain names" would be better

- I think the "non-TLS security protocols" in the 2nd milestone
is too vague, if there are specific protocols for which we'd like
to define support those should be mentioned, or else this
milestone should be preceded by the re-charter one. In other
words, if there're specific protocols other than (D)TLS the
putative WG wants to work with, then those should be called out.
If the only thing of interest is (D)TLS, then one could argue
that this work should just be done in the TLS WG, so it may
well be a good idea to agree at least one other protocol and
put in a milestone for that. (Which of course implies finding
folks who say they'll do the work.)

And lastly, FWIW, I think John Gilmore's suggested text could
also be used as a basis for a charter, though I'd also argue
for changes to that were it to be used as a starting point.

Stephen.