Subject: [dnsop] Key Distribution I-D

From: Ben Laurie <[email-masked]>
Date: Wed, 06 Oct 2004 10:44:45 +0100

The I-D editors seem to be sitting on it, so here's my copy...

http://www.links.org/dnssec/draft-laurie-dnssec-key-distribution-00.txt
http://www.links.org/dnssec/draft-laurie-dnssec-key-distribution-00.html

Abstract:

Until DNSSEC is fully deployed, so-called "islands of trust" will
exist. This will lead to a large number of keys with no method within
DNSSEC to manage the keys.

This proposal seeks to address that issue using existing mechanisms to
allow cross-signing of root (i.e. roots of islands) keys.

This cross-signing of keys creates a non-hierarchical web of trust
which permits the efficient gathering and validation of trust anchors.

Comments welcome, of course. Not sure whether it belongs in DNSOP or 
DNSEXT, hence the crossposting.

Cheers,

Ben.

-- 
ApacheCon! 13-17 November! http://www.apachecon.com/

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Ben Laurie <[email-masked]>
Date: Fri, 08 Oct 2004 17:09:28 +0100

Samuel Weiler wrote:
> General thoughts:
> 
> This is an interesting proposal.  It moves the trust anchor
> distribution out of band and uses X.509 certificate chains for
> authentication.  I have concerns about going out of band (mostly
> having to do with reachability and scaling -- I'd want to be able to
> take advantage of DNS's caching infrastructure), but this is probably
> a very good approach.
> 
> One of the important questions when I look at a proposal like this is:
> "how does a resolver determine which zones it should expect to be
> signed"?  Or perhaps "how can a resolver determine whether a given
> response should be signed"?
> 
> This proposal seems to do this by precomputation: a resolver
> (previously)  downloaded a list of all Island Roots trusted by its
> preferred IRCA, recursed, applied some trust relationships, and
> determined which set of zones should be signed.  And unless the
> resolver has done that prefetching and precomputation, it looks like
> there's no immediate and efficient way, given a particular
> query/answer, to determine whether it should be signed.

Correct, this was intended as a bootstrapping protocol, not a way to 
handle arbitrary queries.

So, the answer would be "it should be signed if you have trusted keys 
for the zone as a result of using this mechanism".

> Another question I tend to ask is: what hoops must a signed zone (or
> IRCA) jump through to change its own keys or to roll back to insecure?
> It looks like this proposal is very egalitarian: any zone wishing to
> be a secure entry point also becomes an IRCA, capable of publishing
> its own list of signed certs.  (Have I got that right?)

Yes. Of course, it is up to the user to choose which IRCAs they trust.

> It also looks like there's no way for an IRCA to know what other IRCAs have created
> and published certs for it, which makes it hard to roll keys or move
> back to insecure, since the IRCA doesn't necessarily know who to talk
> to.   And there's nothing to help a zone that, while the top of an
> island of security, really doesn't want its keys to be statically
> configured in many places.  I'm not sure where the tradeoff here
> should fall.

Well, first off, the process for signing keys should be such that any 
IRCA that has signed your keys that you don't know about is one that 
nobody should trust. So, I'd tend to discount that possibility.

However, once a certificate for a key has been generated, its certainly 
true that you can't get it back again. This is why we have CRLs and 
OCSP. I haven't addressed those yet, but I certainly have to.

This is also why I suggest you use a key that you apply a very high 
level of security to for the IRCA certificates.

> Feel free to tell me if I've gotten something wrong here...
> 
> Nit:
> 
> It's not until section 6 that it becomes clear that an HTTP URL (and
> not, say, an IMAP URL) is being used.  Prior to that, it looks like
> any URL could be used.  (gopher? finger? SMTP? LDAP?)

Any URL that gets you data should work fine, I'm not really depending on 
HTTP. LDAP was even designed for the purpose!

> Security considerations should acknowledge the presumable dependency
> of the HTTP lookup on DNS.  Yes, the data is secured, but there still
> _appears_ to be a circular dependence.  Might as well proactively
> avoid that criticism.

I did address that in the section "Security Non-issues", didn't I?

> Meta:
> 
> Since it appears not to touch the DNS protocols, this proposal looks
> like it belongs in DNSOP.  I know of other proposals that do very
> similar things but which touch DNS enough to belong in DNSEXT.
> Perhaps we should declare one home for all of them, whether or not
> they're mucking with bits on port 53?

It doesn't make sense to me to have them in different homes, that's for 
sure.

Cheers,

Ben.