To:
Scott Rose <scottr@antd.nist.gov>
cc:
Dan Massey <masseyd@isi.edu>, <dnssec@cafax.se>
From:
Simon Josefsson <jas@extundo.com>
Date:
Fri, 4 May 2001 16:53:08 +0200 (CEST)
In-Reply-To:
<003201c0d497$b92da360$b9370681@antd.nist.gov>
Sender:
owner-dnssec@cafax.se
Subject:
Re: keys at apex (key points)
On Fri, 4 May 2001, Scott Rose wrote: > I think the "DNSSEC only" KEY description is the easiest way to go for now. > The problem of how best to store application keys in the DNS (if at all) is > a larger DNS issue, not strictly a DNSSEC issue. My opinion: no new APPKEY RR, KEY was intended for this and we should try to make it work, and if we can't, we'd might rather use CERT. > Do we have people to volunteer to write up each proposal as a lightweight > draft for the WG? This is my attempt to give a objective summary (but given the above you can guess where my preferences are, or at least where they aren't): Three approaches to storing application security keys in DNS ------------------------------------------------------------ Introduction ------------ DNSSEC defines storage of application-level security keys in DNS (for use in e.g. SSH or IPSec). The current definition uses the same RR as is used for securing DNS data itself, the KEY RR. Used naively, this could introduce a few problems, including: * Application KEY's at zone apex * Large KEY RRsets harming DNS(Sec) infrastructure The reader is assumed to be familiar with these problems. Idea #1 ------- Mandate that KEY RR's used for non-DNSSEC uses should use application-specific owner names, such as "host._ssh.example.org". Pro: Solve both problems. Con: The success of this model depends on operational recomendations rather than protocol specifications. Might not be such a big deal. Idea #2 ------- Mandate that the KEY RR is for internal DNSSEC uses only, and use the CERT RR to store application security keys. Pro: Solve both problems. Pro: An "application RR" for application-level security keys, cleanly separating it from DNSSEC keys. Con: The Protocol field of the KEY RR is not used. Con: Certificates != Keys, and CERT RR presumably wasn't intended for storing raw keys. However, CERT RR's support CRL's (!= Certificates) today. I don't see any technical problem of using the CERT RR for both certificates and keys. Idea #3 ------- Introduce a new APPKEY RR for application security keys only. Pro: Solve both problems. Con: The Protocol field of the KEY RR is not used. Con: "Application security" seems like a candidate for storing certificates as well (and some applications don't care about the distinction between certificates and trusted key's), but that would render the CERT RR useless.