[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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-----

Home | Date list | Subject list