[pkng] fyi: keyassure@ mailing list - aka tls@dnssec, certs/keys-in-DNS(sec), DKI

[=JeffH <[e-mail]>]

Of possible interest...

A new pre-BoF list ([e-mail], see below) is discussing 
certs/keys-in-DNS(sec) both as a way to augment present-day PKI, and as a way 
to re-invent it.

In addition to the various references helpfully listed below by Ondrej, there's 
this recent preso by Dan Kaminsky, presented a couple weeks ago at Black Hat...

   Black Ops of Fundamental Defense:
   Introducing the Domain Key Infrastructure (DKI)
   http://www.recursion.com/files/BlackOps-2010.pdf


=JeffH
------
Subject: [keyassure] You want to read this :) (Was: Welcome to the mailing
  list, and possible charter.)
From: [e-mail]
Date: Wed, 18 Aug 2010 09:50:29 +0200
To: [e-mail]

	(text/plain)
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.
 >
 > 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).


-- 
   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:[e-mail]    http://nic.cz/
   tel:[phone]       fax:[phone]
   -------------------------------------------
_______________________________________________
keyassure mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/keyassure