Subject: [keyassure] Alternative Charter Proposal

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 13:12:49 -0400

In response to Paul's request, I propose the following as a better
statement of what the group is trying to do and to not do.

Objective:

Specify mechanisms that allow Internet applications to establish
cryptographically enhanced communications through use of information
distributed through the DNS.

Problem Statement:

Today the Internet is insecure by default and security is the
exception. If the security of the Internet is to be improved, security
must become the default. In particular modern computers have the
ability to employ cryptographic security enhancements with minimal or
negligible impact on performance, yet only a tiny proportion of
Internet traffic is encrypted or authenticated.

One of the key weaknesses of the current Internet Public Key
Infrastructure (PKI) is that the most widely used Internet PKI is
based on the X.500 Directory scheme intended to support an entirely
different networking infrastructure.

The naming infrastructure of the Internet is the DNS, not X.500. While
the PKIX specifications provide a means of mapping X.509v3 attributes
to DNS names there is currently no widely accepted, generalized means
of achieving the mapping from DNS names to X.509 certificates in
particular or to cryptographic keying material in general. DKIM and
SSH have demonstrated the utility of this approach in specific
domains, these specifications

Recent progress in deployment of DNSSEC has renewed focus on the use
of the DNS naming system to support cryptographic operations. In
particular:

  * Discovery of keying material by DNS name
  * Discovery of security criteria by DNS names
  * Verification of keying material through DNSSEC trust chains

Scope:

  * Use of existing security protocols with DNS established keys
  * Use of DNS to verify existing certificate / keysigning / security
assertion material formats
  * Means of verifying key/certificate chains using DNSSEC exclusively
  * Means of verifying key/certificate chains using DNSSEC in
combination with other existing means

Out-Of-Scope:

* Reason for choice of specific trust paths
* New formats for keying material (other than raw keys)
* New trust architectures (unless they can be expressed in existing formats

What I am proposing here is that instead of committing up front to a
view of DNSSEC as being intrinsically opposed to existing PKI schemes
in that charter, we look for way that we can use DNSSEC and existing
infrastructures together.

The biggest mistake made in the PKI world was when the PGP and PEM
people decided that they could not possibly work together and so they
developed to schemes for email security that have competed for
mindshare ever since. Jon Callas and I tried to work out ways of
overcoming the consequences of that choice on many occasions without
much success. The result has been that neither PGP nor SMIME is widely
used.

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Aug 2010 14:16:46 -0400

I disagree with the objective and problem statement here; the  
objective is too vague, and the problem statement seems completely  
unrelated.  I actually started out writing the email not intending to  
write a new charter, but here's another proposal:

Objective:

Specify mechanisms for Internet applications to use information  
distributed through the DNS to establish cryptographically assured  
bindings between domain names and public keys.

Problem Statement:

Many Internet applications require protocol entities to authenticate  
that they represent a certain domain 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.

In the past, these bindings have been asserted by parties external to  
the DNS, using X.509 certificates.  A certification authority (CA) can  
create certificates that contain a domain name (e.g., as a Common Name  
or dNSName Subject Alternative Name) and a public key.  When a server  
presents this certificate and proves ownership of the private key, a  
relying party that trusts the CA to authenticate domain ownership can  
be assured that the server legitimately represents the domain.

One problem with this model is that the CAs that are typically used  
have no relationship to the DNS infrastructure about which they are  
making assertions.  Modern browsers and operating systems typically  
include more than a hundred CAs as trust anchors, any of which can  
create a certificate for any domain name.

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 to providing a more authoritative way of binding  
DNS names to keys, 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.  The group may also specify updates or clarifications  
to protocols to describe how protocol entities discover and validate  
these bindings in the execution of a specific application.

Note that this working group is specifically focused on bindings  
between domain names and public keys, rather than bindings between  
names and other sorts of information.  For example, an X.509  
certificate can associate many types of information with its subject,  
including things like IP address holdings and images of logos, as well  
as bindings to higher-layer identities (e.g., corporate names).   
Mechanisms developed by this group will not be focused on these  
additional data, only on public keys.  This basic binding might be  
used, however, to associate a domain name with rich data by including  
the same public key in the certificate that is bound to the domain.

On Aug 19, 2010, at 1:12 PM, Phillip Hallam-Baker wrote:

> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 15:18:01 -0400

That is still an architectural statement, not a problem statement.

If you want to put statements into the charter asserting the benefit
of one particular trust topology, then you have to accept the argument
over whether those claims are actually true as being in scope for
charter discussions.

If you want to avoid those discussions then simply take the statements
out. They are not necessary.

On Thu, Aug 19, 2010 at 2:16 PM, Richard L. Barnes <[email-masked]> wrote:
> I disagree with the objective and problem statement here; the objective is
> too vague, and the problem statement seems completely unrelated.  I actually
> started out writing the email not intending to write a new charter, but
> here's another proposal:
>
> Objective:
>
> Specify mechanisms for Internet applications to use information distributed
> through the DNS to establish cryptographically assured bindings between
> domain names and public keys.
>
> Problem Statement:
>
> Many Internet applications require protocol entities to authenticate that
> they represent a certain domain 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.
>
> In the past, these bindings have been asserted by parties external to the
> DNS, using X.509 certificates.  A certification authority (CA) can create
> certificates that contain a domain name (e.g., as a Common Name or dNSName
> Subject Alternative Name) and a public key.  When a server presents this
> certificate and proves ownership of the private key, a relying party that
> trusts the CA to authenticate domain ownership can be assured that the
> server legitimately represents the domain.
>
> One problem with this model is that the CAs that are typically used have no
> relationship to the DNS infrastructure about which they are making
> assertions.  Modern browsers and operating systems typically include more
> than a hundred CAs as trust anchors, any of which can create a certificate
> for any domain name.
>
> 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 to
> providing a more authoritative way of binding DNS names to keys, 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.  The group
> may also specify updates or clarifications to protocols to describe how
> protocol entities discover and validate these bindings in the execution of a
> specific application.
>
> Note that this working group is specifically focused on bindings between
> domain names and public keys, rather than bindings between names and other
> sorts of information.  For example, an X.509 certificate can associate many
> types of information with its subject, including things like IP address
> holdings and images of logos, as well as bindings to higher-layer identities
> (e.g., corporate names).  Mechanisms developed by this group will not be
> focused on these additional data, only on public keys.  This basic binding
> might be used, however, to associate a domain name with rich data by
> including the same public key in the certificate that is bound to the
> domain.
>
>
>
>
>
>
>
>
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Aug 2010 15:38:07 -0400

I don't think this text claims that one model is better than another  
(ok, except for the word "problem"), just that they offer different  
characteristics.  Namely, in DNSSEC, the key heirarchy overlays is the  
DNS heirarchy, while with the traditional CA model, the key heirarchy  
isn't related to anything in particular.  If you want, we could  
eliminate the second and third paragraphs that discuss the different  
models, but it seems like the charter should explain why what we're  
doing is different from what has happened in the past.

Neither this charter nor any other document can say anything about the  
"validity" of a trust model.  As always, it's up to the entity that's  
authenticating to choose what system he wants to use to claim an  
identity, and it's up to an RP to decide what he trusts.

The only question about trust models that is germane to the charter  
discussion is whether there exist domain operators who want to assert  
name/key bindings in the DNS for use with security protocols, and  
whether there are relying parties who would be interested in using  
this information.  If the answer is "yes", then the work should  
proceed, IMO, with about the scope described below.  And the sense I  
got in the room in Maastricht was that the answer is "yes".

--Richard

On Aug 19, 2010, at 3:18 PM, Phillip Hallam-Baker wrote:

>> objective is
>> distributed
>> have no
>> information
>> present
>> between