Subject: Re: Key Distribution I-D

From: Samuel Weiler <[email-masked]>
Date: Wed, 6 Oct 2004 20:26:28 -0400 (EDT)

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.

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?)  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.

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

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.

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?

-- Sam

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

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

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

> 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

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.

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

> _appears_ to be a circular dependence.  Might as well proactively

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

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

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