Subject: Re: [keyassure] Hopefully finishing up the charter

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

I see no point in trying to separate TLS applications from non TLS
applications. I don't recall any points that have been raised that are
specific to TLS. This is a PKI proposal, not a protocol proposal.

A better approach would be to propose two drafts. The first containing the
core Key Assurance mechanism and the second containing any implementation
points that are specific to TLS. Or probably better still would be to have a
draft that explains how to use TLS and HTTP, a draft TLS and SMTP and so on.

Then if anyone wants to come along and specify how to support a protocol
other than TLS, they can. I suspect that they won't however.

Given how close we are to agreement on the mechanism itself however, do we
need a WG at all?

An alternative approach would be to use the new mechanism for proposing new
DNS RR and sub-RR codes.

There are really two parts to the problem here. One is to design the
mechanism as best we can, the second is to determine what the mechanism
delivers.

I think that working out exactly what the mechanism delivers will take
actual implementation and deployment. But we can certainly understand and
document the mechanism well enough to justify the RR code allocations.

On Wed, Sep 15, 2010 at 8:56 PM, Paul Hoffman <[email-masked]> wrote:

> Greetings again. I have updated the propsed charter at <
> http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure> to cover the two
> issues that were discussed earlier on the mailing list: the troublesome
> sentence about updating application protocols, and the lack of proposed
> deliverables.
>
> The deliverables I made up for this proposal are:
> Nov 2010   First WG draft of protocol for using DNS to associate hosts with
> keys for TLS and DTLS
> Jan 2011   First WG draft of protocols for using DNS to associate hosts
> with non-TLS security protocols
> Jun 2011   Protocol for using DNS to associate hosts with keys for TLS and
> DTLS to IESG
> Aug 2011   Protocols for using DNS to associate hosts with non-TLS security
> protocols
> Aug 2011   Recharter
>
> The first one could be any of the three drafts recently discussed on the
> list. The second could be similar to the first, but applying to protocols
> such as IPsec and so on. If the WG wants, we don't actually have to have a
> second document; that milestone could just be part of the one main document.
> I put the "recharter" at the end because we might have thought of other
> things we want to do and can ask the IESG if we can do them as a WG.
>
> People said that they thought that we should attempt to become a WG as soon
> as we can, and in order to do that, we need a defensible but not perfect
> charter. There will be a call for comments in the IETF for whatever charter
> we pass to the IESG, so changes can be made after that discussion. As long
> as we hit the points that are generally agreed to here, we are probably
> doing fine.
>
> Thoughts?
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Sep 2010 14:04:29 -0400

As I stated in my other post to the list, the charter needs to be explicit
as to what sets of requirements are in or out of scope. I see three possible
requirement areas that could be addressed:

1) Key Assurance.
2) Describing trust path constraints for a domain
3) Security Policy statements.

My assumption was that this group was going to be restricted to the first,
which is what I got from reading the original mailing list announcement and
the initial drafts.

It has become clear however that some people are proposing addressing
restriction of trust roots as well. In particular they want to establish an
implicit assertion that if there is a CERT statement in the DNS that all
keys for that zone MUST have a DNS CERT statement or be considered invalid.

I object to any charter that does not make the scope of the working group
clear in this respect.

It is my belief that the problem of key assurance can be separated from
restriction of trust roots and making of security policy statements. This is
what we have done in every previous PKI scheme that we have developed, both
in the IETF and in the industry.

I do not believe that we can separate the other two concerns. I see no value
in specifying restrictions on trust roots for use with TLS unless we also
have a mechanism that establishes a requirement to use TLS.

Conflating the first two issues, as the Hoffman et. al. draft does, is very
worrying to me because it means that the only way I can make use of the
trust path restrictions is to publish an assurance for each one of my
end-entity certs in the DNS.

If what we are really trying to achieve here is the trust path restriction
and the key assurance is secondary, then why not simply define a mechanism
that allows an enterprise that runs a PKIX CA to simply publish a DNS
statement to the effect that every valid PKIX cert for the domain will have
a trust root to a specified root?

The following two paths are equally acceptable to me:

1) Allow the WG to consider all three requirements but require that the key
assurance mechanism be independent of any policy or trust path restriction
mechanisms.

2) Restrict the scope of the WG to key assurance alone.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 20 Sep 2010 14:29:03 -0400

I would suggest that the main focus be on "key assurance" alone, where  
"key assurance" == "binding a key or cert or fingerprint to a domain  
name using DNSSEC".

Others can be added in a re-charter if there's interest.

--Richard

On Sep 20, 2010, at 2:04 PM, Phillip Hallam-Baker wrote:

> As I stated in my other post to the list, the charter needs to be  
> explicit as to what sets of requirements are in or out of scope. I  
> see three possible requirement areas that could be addressed:
>
> 1) Key Assurance.
> My assumption was that this group was going to be restricted to the  
> first, which is what I got from reading the original mailing list  
> announcement and the initial drafts.
>
> It has become clear however that some people are proposing  
> addressing restriction of trust roots as well. In particular they  
> want to establish an implicit assertion that if there is a CERT  
> statement in the DNS that all keys for that zone MUST have a DNS  
> CERT statement or be considered invalid.
>
>
> I object to any charter that does not make the scope of the working  
> group clear in this respect.
>
> It is my belief that the problem of key assurance can be separated  
> from restriction of trust roots and making of security policy  
> statements. This is what we have done in every previous PKI scheme  
> that we have developed, both in the IETF and in the industry.
>
> I do not believe that we can separate the other two concerns. I see  
> no value in specifying restrictions on trust roots for use with TLS  
> unless we also have a mechanism that establishes a requirement to  
> use TLS.
>
> Conflating the first two issues, as the Hoffman et. al. draft does,  
> is very worrying to me because it means that the only way I can make  
> use of the trust path restrictions is to publish an assurance for  
> each one of my end-entity certs in the DNS.
>
> If what we are really trying to achieve here is the trust path  
> restriction and the key assurance is secondary, then why not simply  
> define a mechanism that allows an enterprise that runs a PKIX CA to  
> simply publish a DNS statement to the effect that every valid PKIX  
> cert for the domain will have a trust root to a specified root?
>
>
> 1) Allow the WG to consider all three requirements but require that  
> the key assurance mechanism be independent of any policy or trust  
> path restriction mechanisms.
>
> Greetings again. I have updated the propsed charter at <http://trac.tools.ietf.org/area/sec/trac/wiki/Keyassure 
> > to cover the two issues that were discussed earlier on the mailing  
> list: the troublesome sentence about updating application protocols,  
> and the lack of proposed deliverables.
>
> Nov 2010   First WG draft of protocol for using DNS to associate  
> hosts with keys for TLS and DTLS
> Jan 2011   First WG draft of protocols for using DNS to associate  
> hosts with non-TLS security protocols
> Jun 2011   Protocol for using DNS to associate hosts with keys for  
> TLS and DTLS to IESG
> Aug 2011   Protocols for using DNS to associate hosts with non-TLS  
> security protocols
> Aug 2011   Recharter
>
> The first one could be any of the three drafts recently discussed on  
> the list. The second could be similar to the first, but applying to  
> protocols such as IPsec and so on. If the WG wants, we don't  
> actually have to have a second document; that milestone could just  
> be part of the one main document. I put the "recharter" at the end  
> because we might have thought of other things we want to do and can  
> ask the IESG if we can do them as a WG.
>
> People said that they thought that we should attempt to become a WG  
> as soon as we can, and in order to do that, we need a defensible but  
> not perfect charter. There will be a call for comments in the IETF  
> for whatever charter we pass to the IESG, so changes can be made  
> after that discussion. As long as we hit the points that are  
> generally agreed to here, we are probably doing fine.
>
> Thoughts?
>
> --Paul Hoffman, Director
> --VPN Consortium