Subject: Re: [keyassure] Latest spin at the chater...
From: Phillip Hallam-Baker <[email-masked]>
To: Warren Kumari <[email-masked]>
Cc: [email-masked]
Date: Fri, 1 Oct 2010 01:16:24 -0400
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>

I have asked on three separate occasions to have the ESRV draft added to the
list of possible starting points:

Possible starting points for these deliverables include
draft-hallambaker-certhash<http://tools.ietf.org/html/draft-hallambaker-certhash>
, draft-hoffman-keys-linkage-from-dns<http://tools.ietf.org/html/draft-hoffman-keys-linkage-from-dns>,
draft-josefsson-keyassure-tls<http://tools.ietf.org/html/draft-josefsson-keyassure-tls>
 and draft-hallambaker-esrv
*
*
*
*
*
*
*
*If we are doing security policy we should look at all the proposals.

The charter as written is of the form 'here is a technology, we want a WG to
turn it into a standard'. While that is the right approach when there is
significant experience of using actual code, we are not in that position
here.

In particular I disagree with the following:

The group will also investigate publishing security policies that are
related to the use of keying material in the DNS, such as whether
communications must be cryptographically protected.

Please remove " that are related to the use of keying material"

The policy mechanism should be orthogonal to the keying mechanism.

Existing experience of security policy ties the policy to protocols and not
keys. Security policies are of the form 'must use SSL when using HTTP at
example.com' and 'must use SSL with key conforming to trust criteria X when
using HTTP...'

Absent extensive experience of tying policy to keys and a demonstration of
clear benefits resulting from that approach, the charter should leave that
choice open.

I don't see any particular reason to separate TLS and non TLS protocols
either. So far the only aspects of the protocol that are tied to TLS are the
'cert enumeration' mechanism and the cert type identifier.

Given the choice, I would much prefer a key assurance mechanism that
supports any security protocol but only works with X.509 certs than one the
only works with TLS but has the option of using additional cert formats that
are either essentially historic or make no real sense in the context of a
hierarchical naming structure (PGP).

I find the milestones to be entirely unrealistic.

It will take considerably longer than June 2011 to have any draft with the
cert enumeration semantics contained in it ready for the IESG. It would be
somewhat optimistic to expect to have a draft with only the key assurance
semantics ready in that time, and that is work we have twenty years
experience doing at this point.

The natural place to break the problem is between key assurance and security
policy. That is, along the major functional lines.

I would anticipate the final document set looking something like

* Key Assurance Mechanism
* Use of Key Assurance Cert Type with HTTP/TLS
* DNS Security Policy Mechanism
* Use of Security Policy with HTTP
* Use of Security Policy with SMTP, POP3, IMAP

For each of the 'Mechanism' documents I would anticipate an effective 3 step
process of Experimental, Proposed, Standard.

For the Use documents I would anticipate a 2 step process starting at
Proposed and going to Standard.

If Russ' 2 step proposal goes through then the final step would be 'Full
Standard' otherwise it will most likely be 'Draft'.

I would also leave open the possibility that there may be multiple
experimental mechanism documents in the case that there is no agreement
before test deployments start.

The reason I propose using the experimental step is that I want to start
real world trials as soon as possible and want the results of those trials
to feed into the Proposed Standard. And to do trials, I would like to have
possible production code points assigned.

Based on previous IETF experience, three years for getting the documents of
this type to Proposed Standard is rather more realistic than the schedules
proposed.

On Thu, Sep 30, 2010 at 8:06 PM, Warren Kumari <[email-masked]> wrote:

> Hi there all,
>
> I wanted to thank everyone for their hard work and active involvement in
> the chartering discussions.
>
> I have reread most of the mail on this topic, and have tried to integrate
> everyones suggestions, and I think that we finally have a version that will
> be *acceptable* to everyone.
>
> I'd like to especially thank Stephen Farrell for his suggestions (which I
> somehow filed into a different label and missed) as well as Phillip, Paul,
> Richard and Jakob for their input and suggested text...
>
> I think that we have been fairly close to an acceptable charter for a long
> time now, but were getting hung up on misunderstandings and
> misinterpretations of what others were saying...
>
> So, please have another look at the charter and hopefully you will find it
> acceptable to you:
> http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure
>
> If parts are not acceptable, please do me 3 favors:
> 1: Reread the unacceptable parts and try figure out if what you are
> objecting to is what the sentence is trying to say, or it is just a wording
> issue / differing uses of a term.
>
> 2: If  you are OK with it being in the charter so that we (as a WG) can at
> least discuss the issue and come to consensus.
>
> and, most importantly:
> 3: send text --- saying "Bah, paragraph X is the devil! eat flaming death,
> mongrel!" is *not* helpful... "How does the group feel about 'Foo blargh
> wumblet boop' instead of 'mumble'?" is...
>
> W
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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