Subject: Re: I-D ACTION:draft-ietf-dnsext-ad-is-secure-03.txt

From: Brian Wellington <[email-masked]>
Date: Tue, 24 Jul 2001 10:02:09 -0700

On Tue, 24 Jul 2001, Ted Lindgreen wrote:

> [Quoting Brian Wellington, on Jul 24,  1:02, in "Re: I-D ACTION:draft ..."]
> > On Mon, 23 Jul 2001, Jakob Schlyter wrote:
> >
> > > On Mon, 23 Jul 2001, Brian Wellington wrote:
> > >
> > > > Let's say I have a signed zone.  I signed it myself.  I configured the
> > > > server myself.  I tested the server to make sure it's returning the right
> > > > answers, and they authenticate.  I know everything's correct.  Why can't
> > > > my server set the AD bit?
> > >
> > > because the signature will expire and you will set the AD bit on data that
> > > is no longer authenticated.
> >
> > Not necessarily.  If I properly manage my zone, I'll have resigned it and
> > reloaded the server before the data expires.  Again, it's local policy.
> > I trust myself to manage my secure zone.
>
> The problem is that BIND-9 is forcing the world to adopt your policy
> to "properly manage my zone", while practice has learned that many
> systemadministrators have a hard time doing that always and timely.

No it isn't.  BIND 9 supports the "never set the AD bit on authoritative
zone" policy.  It has the advantage of being the cleanest to implement.

See the message posted earlier today by Roy Arends on how to set up BIND 9
with multiple views to get verification of authoritative data.

> From the .nl.nl DNSSEC experiment, running for over a year now, we
> have experienced, that none of the participants, including ourselves,
> have managed to always resign their zones in time. In most cases,
> sig-expires are followed by a period, where the sigs remain expired
> until someone notices it and warns, and someone else says "Ooops" :-)

I can honestly say that I have no experience running a production signed
zone.  If I did, I'd probably use cron to remind myself to resign it.

> As an off-topic side note: how do we find out that sigs are expired?
>  We run good-old bind-8 on one of the secondary servers, which we
>  periodically restart.  In contrast to bind-9, bind-8 complains
>  loudly when started with outdated signatures. However, I would
>  like to retire bind-8 someday....

Find and/or write an external program to do this.  The fact that bind 8
does signature checking on load makes it unacceptably slow to start.  It's
possible that bind 9 will at least do expiration checking on load at some
point, but not anytime in the near future.

Brian

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 24 Jul 2001 10:41:42 -0700

>point, but not anytime in the near future.

It seems that non-cryptographic checking of signatures seems to be at least
a compromise solution.  This means validity period, other semantic checks,
but exclusive of building the key chain and even a local verification
(meaning the key is on hand).

Although I have been arguing for verify-on-send/reply, I should be clear
that I realize that this is an onerous operation and I believe this isn't
to be the norm (given the assumption that resolvers look for AD <or> AA).
There have been some research applications where this feature would be
desirable, which is why I've expressed that it should be an option (and I'm
willing to live with this as an unimplemented option so long as ISC will at
some time accept patches to BIND if the research applications ever perform
the implementation).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

You fly too often when ... the airport taxi is on speed-dial.

Opinions expressed are property of my evil twin, not my employer.