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
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.