Of possible interest...
A new pre-BoF list ([email protected], 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: [email protected]
Date: Wed, 18 Aug 2010 09:50:29 +0200
To: [email protected]
(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:[email protected] http://nic.cz/
tel:+420.222745110 fax:+420.222745112
-------------------------------------------
_______________________________________________
keyassure mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/keyassure
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
