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

From: Brian Wellington <[email-masked]>
Date: Fri, 20 Jul 2001 11:33:17 -0700

On Fri, 20 Jul 2001, Roy Arends wrote:

> Hello, I would like to see some clarifications on the ***** marked
> sections.

> *****
> OK bit as in DNSSEC OK bit, specified in draft-ietf-dnsext-dnssec-okbit-02.txt
> ? If this is the case, please refer to it as DO (DNSSEC OK) bit.
> *****

Sure.  Olafur, want to fix this, since you have the source?

>                A DNS server following this modified specification will
>    only set the AD bit when it has cryptographically verified the data
>    in the answer. In the case of a primary server for a secure zone,
>    the data MAY be considered Authenticated, depending on local policy.
>
> *****
> I don't know how to read this.
>
> In the case of a primary server for a secure zone, the data MAY be
> considered Authenticated, depending on local policy, when what ?
> When the AD bit is set ? May it set the AD bit if it is the primary server
> for a secure zone, though the zone is actually not authenticated by the
> server ? The last sentence of the above section is a bit confusing.
> *****

"Authenticated" is a term defined in RFC 2535, section 6.  It is normally
used when referring to the security status of data on a recursive server.
This particular text says that the server may consider locally configured
data to be in the "Authenticated" state.

>    Secondary servers SHOULD NOT consider data Authenticated unless the
>    zone was transfered securely or the data was verified.
>
> *****
> or ? So if the zone was transferred securely, the secondary can consider
> the data Authenticated (and thus, set the AD bit) when it actually did not
> verify the contents of the zone ? I don't like it.
> *****

If the zone is transferred securely, then the secondary is guaranteed to
have the same data as the primary.  The primary is allowed to set AD
without verifying the data also.

>    This document redefines a bit in the DNS header.  If a resolver
>    trusts the value of the AD bit, it must be sure that the server is
>    using the updated definition, which is any server supporting the OK
>    bit.
>
> *****
> What are the implictions for the AD bit when the CD bit is set in a query.
> MAY/SHOULD[NOT]/MUST[NOT] a response have the AD bit set when CD (and
> optionally DO) bit is set ? The resolver is probably not interested in AD
> bit when CD bit is set, but a clarification would be good.
> *****

There are no implications.  Whether the AD bit is on in a response
reflects the security status of data, not whether CD was set in the query.
Even if CD is set, the response can have AD set if the data had already
been verified.

Brian

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

---

From: Roy Arends <[email-masked]>
Date: Fri, 20 Jul 2001 11:38:20 -0700

> data to be in the "Authenticated" state.

Ah, so without cryptographicly authenticating the data which is read
from disk, the primary could set the AD bit on responses since it may
consider locally configured data to be in authenticated state.

I totally object to this.

I also do not see a reason for this.

> without verifying the data also.

I totally object to this !

TSIG/SIG(0) can transfer a zone securely, even if the data at the
primary is corrupt.

Only when a server (caching or authoritative) has cryptographicly verified
(according to the local policy) the contents of the answer and authority
section in a response its about to give out, the AD bit may be set.

IMHO local policy MUST NOT include setting AD bit while the contents are
actually not cryptographicly verified.

> Even if CD is set, the response can have AD set if the data had already

I agree totally, but IMHO it would be good if this independence of CD (and
DO) is documented.

Regards

Roy

---

From: Roy Arends <[email-masked]>
Date: Fri, 20 Jul 2001 11:42:07 -0700

On Fri, 20 Jul 2001, Brian Wellington wrote:

> This discussion has already been had several times.

I am aware of that.

> If you don't trust the on-disk zone data, why would you trust anything
> else about the server? A key configured into named.conf could be
> maliciously or accidentally changed in the same way as the master
> file.  The data could expire at some point after the server was
> loaded, and the server would still give out bad data.  In short,
> verifying data on load has no positive effects, and has the huge
> negative effect that it exponentially increases server load time.

So why not authenticate data on query. That solves the server load
problem. Next to that, drop the data (or at least the AD indication) if
the sig is expired.

> Treating on-disk signed data as "Authenticated"  is reasonable behavior,
> and a server may choose to implement this policy.

This is not acceptable to me. Authenticated data is simply authenticated
data, regardless where it comes from. Don't set the AD bit if the data is
not authenticated.

> Again, this is not true.  You agree that a secure transfer guarantees that
> the secondary has the same data as the primary, so if the primary trusts
> it, the secondary should also.

I agree on the part that the secondary will have the same data as the
primary, when securely transferred. But still, the data may be corrupt.

TSIG/SIG(0) authenticates resolvers, servers, and will preserve data
integrity during transport. Thats it. The data itself may be totally
corrupt. DNSSEC is used for origin authentication, and the AD should
reflect that. Origin as in Domain, not Server.

Regards,

Roy Arends
Nominum

---

From: Roy Arends <[email-masked]>
Date: Sat, 21 Jul 2001 00:40:37 -0700

Ha ! , responding to myself :-)

Anyway, after an offlist discussion between Brian and myself, I understand
and agree with his point of view. It boils down to the following:

AD bit indicates data has been authenticated. A cache MUST have
authenticated the data when it has the AD bit set on responses.

Authoritative and signed data, stored on disk, may have been authenticated
already, and therefor authenticating it again is doubling the effort.

If an adminstrator authenticated the data on disk according to its policy,
it may instruct the server to treat it as such, without having the server
actually authenticate the data itself.

Ofcourse this could mean that the data served by an authoritative server
is not authenticated at all while the AD is set, but that is the
responsibility of the administrator/domain holder.

So, apart from a few small clarifications, I agree with the draft.

Regards,

Roy Arends
Nominum

---

From: Edward Lewis <[email-masked]>
Date: Mon, 23 Jul 2001 11:12:13 -0700

>responsibility of the administrator/domain holder.

Gaack, no!

Please don't set the AD bit without locally verifying the data.  I'd rather
have to have the resolver check for either AA or AD than have the AD bit
mean something inconsistently.  (1 bit = YES/NO, not = YES/NO/MAYBE.)

As far as a the arguement that a stub (non-crypto-doing) resolver would
always be using a recursive server, I think this is 1) wrong and 2)
restricive.

Wrong because most of my lookups are for local sites (fileserver.<domain>,
smtp.<domain>, pop.<domain>) as opposed to remote sites
(www.sportsscores.com).  The server I use for recursion is also
authortiative for <domain>, hence, my stub resolver is usually going to the
authortitative source for data.

Restrictive because you are assuming that everyone will run DNS in one way.
It used to be (not long ago) that BIND tried to encompass the wide range of
configurations that folks put it through.  Now it seems that more and more
it is being designed for just one best way of use.

Why can't the authortitative server be made to optionally "verify on send"
and thus set the AD bit that way?  Why do I have to buy into the mantra "I
just trust what's on my disk?"

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

---

From: Brian Wellington <[email-masked]>
Date: Mon, 23 Jul 2001 12:00:05 -0700

On Mon, 23 Jul 2001, Edward Lewis wrote:

> I can't resist the following observation:
>
> At 2:10 PM -0400 7/23/01, Brian Wellington wrote:
> >Nobody seems to understand that verify-on-reply is a bad idea.  An
> >authoritative server is designed to serve data, that's it.
>
> Ergo, the consensus is that verify-on-reply is a good idea?

Er, no.  If everybody jumped off a bridge...

Brian

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 23 Jul 2001 13:47:34 -0700

On Mon, 23 Jul 2001, Brian Wellington wrote:

> > verify-on-send could of course be configurable, as recursion is in some
> > servers.
>
> I'd much prefer to see a server with a "recursive" view and an
> "authoritative" view, where all recursive querie went through the
> recursive view.  This would allow the server verify authoritative data
> (when the query has the RD bit set), without complicating the
> authoritative server.

this sounds reasonable.

perhaps we should go back to discussing the draft?

I still think that the draft should say that you MUST NOT set the AD bit
without cryptographic verification of data. could we agree on this? if the
server should try to verify the data at all is an implementational issue.

	jakob

---

From: Brian Wellington <[email-masked]>
Date: Mon, 23 Jul 2001 15:44:23 -0700

On Mon, 23 Jul 2001, Jakob Schlyter 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.

> I've assumed that authenticated means "authenticated using DNSSEC". if you
> have another definition, your may be correct.

RFC 2535:

Authenticated means that the data has a valid SIG under a KEY traceable
via a chain of zero or more SIG and KEY RRs allowed by the resolvers
policies to a KEY staticly configured at the resolver.

That's the definition I've been using.

Brian

---

From: Roy Arends <[email-masked]>
Date: Mon, 23 Jul 2001 16:36:43 -0700

On Mon, 23 Jul 2001, Olafur Gudmundsson wrote:

> There is an extra dimension missing from this arguement, Nameserver trust.
> Resolver either trusts a nameserver (by policy) or it does not!
>
> If I configure my resolver to trust noone then it will verify all
> signatures. If I configure it to trust cr.yp.to. then it will verify all
> signatures execpt the ones that come from cr.yp.to. with the AD bit set.
>
>
> > 1) Don't trust AD, unless TSIG/SIG(0) is used.
>
> I think you want to say,
> Do not trust AD unless message is authenticated AND from a
> trusted nameserver.

Yes.

> > 2) If you do TSIG/SIG(0) to an authoritative serve you implying you trust
> >    the authoritative server.
>
> TSIG only authenticates the message and origin, what resolver does
> with the contents depends on policy, it may or may not trust the
> server.

If the local trust policy of a resolver states "trust a query-response
with the AD bit set from ba.di.mp" it would be worthless without stating
"only trust AD bit for ba.di.mp when transaction is validated" (implying
some secure transaction, maybe even TSIG/SIG(0)).

As I said, using TSIG/SIG(0) to an authoritative server the resolver
implies that it trust the authoritative server. The contents coming from
that server is a different thing. If the AD bit is set, a server indicates
that it validated the contents in the answer/authority section according
to its own policy. Keyword here is _server_. Now, if the resolver can
trust the server (or message from that server), it can trust that the AD
bit was indeed set by that server.

Indeed, if it will/wants to/can trust the contents, following its own
policy, is up to the resolver.

> > 3) If you trust the authoritative server, you don't need the AD bit.
>
> Correct, in the case of authorative data from that server,
> For authorative answers (AA set), AD is redundant.

Exactly !

> but if AA is not set then AD has value.

Exactly !

Roy Arends
Nominum

---

From: [email-masked] (Ted Lindgreen)
Date: Tue, 24 Jul 2001 07:47:56 -0700

[Quoting Brian Wellington, on Jul 24,  1:02, in "Re: I-D ACTION:draft ..."]
> 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.

>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" :-)

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

Regards,
-- ted

---

From: Brian Wellington <[email-masked]>
Date: Tue, 24 Jul 2001 11:54:54 -0700

On Tue, 24 Jul 2001, Edward Lewis wrote:

> At 12:19 PM -0400 7/24/01, Brian Wellington wrote:
> >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.
>
> 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).

 944.   [func]          Check for expired signatures on load.

It only prints one warning per zone, since the BIND 8 method of filling up
syslog with hundreds of messages is silly.

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

Would such an implementation offer anything over the multiple-view
solution?

Brian

---

From: [email-masked] (Ted Lindgreen)
Date: Wed, 25 Jul 2001 06:25:13 -0700

[Quoting Brian Wellington, on Jul 25,  0:32, in "Re: I-D ACTION:draft ..."]

> This is not a BIND issue.  It's a fundamental problem that DNSSEC
> verification is slow, and the authoritative server should not be doing it.

I do not think that many people on this list agree with this statement.
The main question was:
When an authorative nameserver sets the AD, is it then:
- A MUST that the nameserver software makes sure the data is sane?
- Is it sufficient to rely on the fact that the data comes from disk
  and that the sysadm has taken care of putting valid data there
  and always refreshing the sigs in time?

I think many of us, especially those with operational experience
in large scale production environments, think that the latter is
not sufficient.  Further, I personaly think that not setting the
AD bit and splitting functionality of authorative and caching
servers are just workarounds.

If efficiency is a big issue, I think that everybody can very well
live with more efficient procedures than a verify on each and every
query, like a one-time verify on startup, reload and AXFR, plus a
timer to prevent unnoticed sigexpires. I don't think that many
people will agree that just omitting all sanity checks are the
solution to efficiency problems.

Regards,
-- ted

PS. About your confusion:

> I'm confused as to how "almost everyone" agrees with this.  From what I
> can tell, there are about 5 people participating in this discussion, and
> only 3 are in favor of this.

Indeed, in the last discussion only 5 people spoke up, but this
issue is not new. It has been a topic on at least 4 IETF meetings,
4 RIPE meetings, other (ccTLD) meetings and conferences, and more
DNSSEC workshops than I can remember exactly how many.

Sofar, almost everybody I heard about this issue, had the opinion,
that secure aware nameservers, including and especially authorative
nameservers, should be careful not to produce data with bad and/or
expired sigantures. During the various workshops, everybody, without
exception, was amazed, to say it mildly, on finding out that BIND-9
does not do any checking on the data it's authorative for and
starts up and happliy answers with outdated SIGs.

My statement "almost everyone" was based on this experience.  But,
my remark, that the current software, BIND-9, does not do any sanity
check on SIGs, while the former BIND-8 release did a resonable job
here, is an implementation issue and indeed off-topic on this list,
for which I apologise.

--

---

From: Brian Wellington <[email-masked]>
Date: Wed, 25 Jul 2001 09:58:40 -0700

On Wed, 25 Jul 2001, Ted Lindgreen wrote:

> Yes, that's what I expected to hear. Actually, we are trying to make
> extentions on "host" and "dig", like it was available in Bind-8, to
> perform SIG verification. However, e-mail exchange with  Brian made
> clear, that such extentions are not desired and will definately not
> ever be included in BIND-9.

You're taking things out of context.  I said that it's not likely that
these extensions would be added to dig or host, because dig and host are
already bloated enough, and validting chains of signatures is not in the
spirit of what they're supposed to do.  I said that this should be a
separate, and see no reason why the separate tool could not be included.

The dig and host extensions in BIND 8 never worked very well, in my
opinion.  I'd prefer to see something good.

> So, I'm a bit confused, again. We, NLnet Labs, think that SIG
> verification tools should be a necessary part of BIND.

I agree.  Just not as a part of dig or host.

Brian

---

From: Brian Wellington <[email-masked]>
Date: Wed, 25 Jul 2001 09:48:18 -0700

On Wed, 25 Jul 2001, Jakob Schlyter wrote:

> On Tue, 24 Jul 2001, Brian Wellington wrote:
>
> > verify-on-query is incredibly inefficient, even for small zones.
> > Authoritative DNS servers can easily answer thousands of queries per
> > second.  Modern computers can maybe do a few hundred signature
> > verifications per second.  Combined with other overhead, I'd be surprised
> > if a server doing verify-on-query was less than 10x times slower than an
> > ordinary server.  Would you want to run a server like that?  I wouldn't.
>
> if you combine an acl for which clients to do verify-on-query for with
> only doing verify-on-query when the client resolver indicates DNSSEC
> support (using the EDNS0 DO bit), I do not think this would be a big
> performance issue. it's also a lot easier than the multiple-view magic.

I don't think you understand the architecture of a name server.  There is
a 'server' and a 'resolver'.  The server deals with authoritative data,
and the resolver deals with retrieving and caching data.  These modules
were hopelessly intertwined in BIND 8; they are mostly separate in BIND 9.

All DNSSEC verification occurs in the resolver.  The server is only
responsible for handing out data, either from authoritative zones or the
cache.  If it needs something that's not there, it dispatches a resolver
to get it.

verify-on-query complicates the server, by adding complicated DNSSEC
validation logic, and would require significant changes to the existing
code.

The multiple-view method causes recursive queries to enter the server in
such a way that it doesn't consult authoritative data directly, but only
cached data.  Before it is cached, data is retrieved from the
authoritative view, and normal processing causes it to be DNSSEC
validated.  This works now.  It's not much more complicated - about 10
lines of named.conf to define a second view.

Yes, I think this is getting off topic for namedroppers, but I completely
fail to comprehend why the existing solution is not sufficient.

Brian

---

From: Brian Wellington <[email-masked]>
Date: Sat, 28 Jul 2001 08:24:09 -0700

On Fri, 27 Jul 2001, Ted Lindgreen wrote:

> [Quoting Brian Wellington, on Jul 26, 18:06, in "Re: I-D ACTION:draft ..."]
> > On Thu, 26 Jul 2001, Ted Lindgreen wrote:
> >
> > > Note: It would have been different, if BIND in the "recursive view"
> > > would actually check the data it is authorative for query-time,
> > > but as far as I know this is not in the code at the moment.
> >
> > You missed the point again.  In the "recursive view", there is no
> > authoritative data.  There is only cached data.  If the cached data is
> > obtained from the "authoritative view", it's treated just like data
> > obtained from any other source, meaning it is validated at the time it's
> > received and the TTL is properly clamped.
>
> Dear Brian,
>
> I stand corrected, indeed, I did not understand that from the
> same server, you get different answers, depending on to what view
> you belong. Your answer made me further very happy, as it now
> appears, that with some careful configuration the software can do
> something close to what we want (be careful not to advertize data
> with bad and/or outdated sig's).

Good.

> However, my happiness did not last very long :-(
>
> Of course, I tried it out immediately to see how we can adopt
> this scheme in our DNSSEC testbed for .nl.nl.
>
> However, after trying out various configuration setups I found out,
> that setting up multiple views is extremenly tricky, especially if
> your systems are authorative for various domains at different levels
> in the tree. Although we are doing something special with DNSSEC,
> I don't think our tree-structure is very uncommon in the real world.

It shouldn't be tricky.  If you describe what you did (to a more
appropriate place, like bind9-users), someone might be able to find the
problem.

> After reconfigurating for 6 hours now, I still have not found
> a configuration, that would reliably produce verified data where
> I want it to do that, and to provide authoritive data where it must
> do that to prevent the delegations from getting lame.

Yes, this is a real problem.  Fortunately, I'm one step ahead of you.
Added yesterday:

 945.   [func]          Add the new view-specific options
                        "match-destinations" and "match-recursive-only".

"match-recursive-only" will allow recursive clients to match the recursive
view, while non-recursive clients (such as forwarding servers and zone
transfer clients) to match an authoritative view.  This will be in BIND
9.2.0b2, due (I think) Monday.

> I've given up now, and only left the testdomain "ted.dnssec.nl.nl"
> secured on a dual view server in case any anyone is interested to
> look at it: sanne.nlnetlabs.nl is the dual-view server, and
> auth-parent-servers plus its own secondaries are in the auth. view;
> the rest of the world in the recursive view; with
>  dig @sanne.nlnetlabs.nl +dnssec -t txt ted.dnssec.nl.nl
> you can see, that sometimes the answer is as Brian predicted above,
> and sometimes you get "SERVFAIL". I have not been able to find out
> what the reason for this inconsistance is.

It's probably that problem with nonauthoritative answers.  Can you try
the same setup with 9.2.0b2 when released?

> Because of trickyness and the stability problem, I reverted to the
> old setup for all other domains, where bad and outdated sigs are
> happily provided.
>
> PS. To go back on topic: I still think that it's a hack, and that
> it is better to have the AD-bit to mean the same thing in every
> view or context.

It does mean the same thing in every context.  The current version of BIND
9, for example, only sets AD when the data has been verified.  Unless I'm
mistaken, this is exactly what you're arguing for.  The "bad or outdated"
SIGs are coming from an authoritative zone, and the AD bit is not set.

Brian

---

From: [email-masked] (Ted Lindgreen)
Date: Sat, 28 Jul 2001 08:08:08 -0700

Dear Brian,

I sure hope, that the average system administrator is more clever
than I am.

Regards,
-- ted