Subject: [keyassure] Welcome to the mailing list, and possible charter.

From: Warren Kumari <[email-masked]>
Date: Tue, 17 Aug 2010 13:21:49 -0400

Hello all, 

We are investigating starting a working group to leverage the DNSSEC trust anchor as a trust anchor for various other protocols. We are initially focusing on TLS, but are also interested in other protocols.

Just so that we are all level set, here is our initial (draft) problem statement.

Problem Statement:

The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS.

The DNSSEC signed root infrastructure provides a single, well published trust-anchor and a method to build a chain of trust from an individual resource record (RR)  to that TA. By leveraging this infrastructure we can securely bind information (such as a public key, certificate identifier, etc) to a DNS name.

Increasingly people would like to be able to take advantage of the confidentiality and identity validation provided by protocols such as TLS. There are numerous barriers to this, including cost, ease of use, complexity, certificate management, etc. By allowing users to securely publish public key information we can allow users to easily and securely make use of self-signed certificates.

Currently, one of the issues limiting the use of self-signed certificates is the difficulty in key-distribution - it is infeasible to distribute a key binding at the web scale. By providing a means to publish (and securely validate) this information in the DNS, we allow for users to attest to the validity of keying information and establish trust in the published public key.

The DNSSEC root trust anchor can also be used for additional validation during the current path validations. By validating that the  certificate presented is the certificate identified by the DNS, we can provide additional confidence that the client is connecting to the intended server - this helps alleviate concerns that a valid certificate has been obtained by an attacker (for example from a CA not used by the victim).

Warren

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 18 Aug 2010 09:50:29 +0200

Just to add some reading material to the mailing list archive...

You may want to read:

New I-D by Jakob, Paul, Warren and Adam:
http://www.ietf.org/internet-drafts/draft-hoffman-keys-linkage-from-dns-00.txt

Slightly older CERT RR (which we already have):
http://tools.ietf.org/html/rfc4398

And various older proposals which didn't make it:

(Jakob's)
http://stupid.domain.name/ietf/draft-schlyter-pkix-dns-02.txt

(RR TYPE request I did)
http://www.ops.ietf.org/lists/namedroppers/namedroppers.2009/msg00421.html

This is just to summarize the ideas which were floating around for some 
time.  The basis on our work will be in the most recent I-D.

On 17.8.2010 19:21, Warren Kumari wrote:
> Hello all,
>
> We are investigating starting a working group to leverage the DNSSEC
> trust anchor as a trust anchor for various other protocols. We are
> initially focusing on TLS, but are also interested in other
> protocols.
>
> The DNS Security Extensions are a collection of resource records and
> protocol modifications that provide source authentication for the
> DNS.
>
> The DNSSEC signed root infrastructure provides a single, well
> published trust-anchor and a method to build a chain of trust from an
> individual resource record (RR)  to that TA. By leveraging this
> infrastructure we can securely bind information (such as a public
> key, certificate identifier, etc) to a DNS name.
>
> Increasingly people would like to be able to take advantage of the
> confidentiality and identity validation provided by protocols such as
> TLS. There are numerous barriers to this, including cost, ease of
> use, complexity, certificate management, etc. By allowing users to
> securely publish public key information we can allow users to easily
> and securely make use of self-signed certificates.
>
> Currently, one of the issues limiting the use of self-signed
> certificates is the difficulty in key-distribution - it is infeasible
> to distribute a key binding at the web scale. By providing a means to
> publish (and securely validate) this information in the DNS, we allow
> for users to attest to the validity of keying information and
> establish trust in the published public key.
>
> The DNSSEC root trust anchor can also be used for additional
> validation during the current path validations. By validating that
> the  certificate presented is the certificate identified by the DNS,
> we can provide additional confidence that the client is connecting to
> the intended server - this helps alleviate concerns that a valid
> certificate has been obtained by an attacker (for example from a CA
> not used by the victim).

-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 18 Aug 2010 07:45:46 -0700

Greetings again. A gang of us created a draft that pulls together some of the many ideas that have been floating around. There are multiple options for some features, so we chose one option in each category and started an appendix to document the choices.

<http://www.ietf.org/id/draft-hoffman-keys-linkage-from-dns-00.txt>

Discussion is welcome. Please don't assume that any of the options are set in stone, although note that changing some options might also require changing other options at the same time. In particular, I think my idea of listing ports is going to go away, given that few sites run services on different ports but keep the same domain name.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Aug 2010 01:13:12 +0100

Quick question: did you consider DKIM key records for this?
(With a new "s=" value in the TXT RR.)

If so, why don't they rate a mention? If not, maybe worth a
look?

S.

On 18/08/10 15:45, Paul Hoffman wrote:
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Aug 2010 10:59:47 -0400

I took another look at DKIM. We do have a few differences. One of the most important being that we are pretty much assuming DNSSEC capable clients and infrastructures. So we are looking at at least one new RR and I think we need three if we are going to do a complete job.

The big question at this point in my view is whether the format is DKIM style unrestricted text field with a registry of tags or a DNS style byte code field approach with fixed fields.

I don't much care about the bit packing issue but I definitely want extensibility.

This is not a massively difficult problem but we may make it one if we have a fixed format record as NXT was. I don't want to have to create a new RR for each iteration of the design. I want an extensible record format.

Whether people agree with me or not on the need for my approach, I hope we can agree that pki has proved to be deceptively complex in the past. I can't see that we lose anything from an extensible format. Coming to consensus on a fixed format is going to be impossible.

My experience in this field suggests that it is going to be highly desirable to have a lot of experimentation with different approaches and converge on the ones that work. What works for mail may not work for web may not work for web services.

Sent from my iPad