To:
keydist@cafax.se
From:
Michael Richardson <mcr@sandelman.ottawa.on.ca>
Date:
Fri, 29 Mar 2002 14:24:27 -0500
In-reply-to:
Your message of "Thu, 28 Mar 2002 10:07:22 EST." <v0313030fb8c8debf46d8@[199.171.39.21]>
Sender:
owner-keydist@cafax.se
Subject:
Re: Leveraging trust
-----BEGIN PGP SIGNED MESSAGE----- >>>>> "Edward" == Edward Lewis <lewis@tislabs.com> writes: Edward> At 7:18 PM -0500 3/27/02, Keith Moore wrote: >> if we want the DNS root to hold together, we need to place as little >> strain on it as possible. giving the root additional responsibility >> doesn't strike me as a good way to do this. Edward> Does this mean that we shouldn't sign the root zone? (This may Edward> sound like a sarcastic question, but I don't mean it that way. I Edward> am trying to understand the limits of "as little ... as Edward> possible.") Edward> In one of the older DNSSEC documents, now RFC 2065, is the Edward> following passage: "A resolver should keep track of the number of Edward> successive secure zones traversed from a starting point to any Edward> secure zone it can reach. In general, the lower such a distance Edward> number is, the greater the confidence in the data." Edward> Between that and the comments on the root, would it be acceptable Edward> to rely on a set of SLDs (such as we\'ll-sign-your-data.com) as Edward> anchors of "trust?" Should we re-instrument resolvers of DNS to Edward> know just how many "leaps of faith" were made in evaluating the Edward> integrity of a piece of data? One of the things proposed for SPKI (but never incorporated) by Tatu Ylonen was the concept of k-of-n signers. A signature is valid if at least k signatures of n possible ones check out. This was specifically proposed for getting rid of the root key itself - one would distribute the n keys (but you get to pick, if you want, which ones) which would sign the gTLD and ccTLDs. I'm not sure, but I'll bet that such a model could written in KeyNote as well. This provides for rolling over of the keys in a much easier manner, and also makes the keys much less valuable to steal. You have to collect them all. (They become just like Pokemon....) There are some issues like what are k and n, and who are the n-key holders. One notion is that the n-key holders are the members of the UN and k=12, the size of the security council, but that doesn't prevent 12 other countries from consipiring together. Probably this notion is silly. BUT, back to keys in the DNS. Even if the root can never be signed, that does not make putting infrastructure keys in the DNS wrong. We can via trusted-key {}, TSIG or SIG(0) develop useful cross-certified forests of trust. A well known .arpa. key to sign the reverse zone solves the IPsec Opportunistic Encryption problem. (We just do not really care about .com) {I consider both SecSH and IPsec to be infrastructure, not applications. Applications are things like telnet, rsync or CVS that run can run on top of secure channels} ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: latin1 Comment: Finger me for keys iQCVAwUBPKS/Z4qHRg3pndX9AQFtLgQA0ihoFMjMe7/0A243rfCmlRhuzAj+wU7o ZwE1es7SlBw5hu0Y2gSuNluXnqf5nz5zTKYmpYBByCB8yK/bPgPOUj9K6/9N7++0 FkCAppHMO2RDmOfBGQsPzlqjMhlwEHQKWD2D/BsEZj5dcg7P8ZPw2I9jMPNvqwKo 15+2J7q4qsM= =K435 -----END PGP SIGNATURE-----