Subject: Question about TSIG, AD/AA, and AXFR

From: Edward Lewis <[email-masked]>
Date: Mon, 16 Jul 2001 16:43:44 -0700

I am wondering if there is an unreported protocol problem in the
combination of TSIG, AD/AA, and AXFR.  My concern is that a resolver may
over trust an answer that has come TSIG-protected from a secondary who used
an unsecured AXFR to get its zone data.

Here is the case-by-case breakdown that led me to this concern.  Assuming a
"stub" resolver - one that will rely on query/response security and is not
able/willing to do full chain processing, and only looking at TSIG-covered
answers:

Case TSIG AD AA Server-type
  1    Y   0  1 Primary        "From disk," so it can be trusted
  2    Y   0  1 Secondary      Via AXFR, trustworthy only if AXFR is secure
  3    Y   1  0 Non-auth       Server validated the chain
  4    Y   1  1 anything       Not possible as far as I can tell

DNS Security is supposed to be about protecting the resolver, and here we
have a case (#2) where the resolver can't be sure of an answer's security.
It is fine to recommend that zone transfers use TSIG, but then you're
putting discretion in the hands of the zone and not the resolver.  (Not to
mention that TSIG isn't the only way to secure an AXFR.)

Can there be some way to indicate that a secondary has used a secure means
to acquire the zone data?  (Yeah, "can there be some way to indicate that a
*primary* has used a secure means to acquire the zone data?" is the first
rebuttal.  But we know that a secondary had to get its data from some other
machine, so I think this asking about a secondary's source is valid.)

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

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

---

From: Brian Wellington <[email-masked]>
Date: Tue, 17 Jul 2001 05:22:17 -0700

> machine, so I think this asking about a secondary's source is valid.)

I don't know how important this is.  As you say, there's no way to
guarantee that the primary has obtained the data securely.  If the
administrators of the secure zone cares enough to sign the zone on a
periodic basic and guarantee that the primary is serving it properly, they
should care enough to ensure that zone transfers are secured.  Especially
since TSIG is signficantly easier to set up than DNSSEC.

Are you talking about the stub resolver directly contacting a secondary?
It should be going through a recursive server, and the recursive server
will validate the data.  If the data on the secondary has been corrupted
or maliciously altered, the recursive server will fail to verify it.
About the worst can happen is that the secondary can serve data that's no
longer in the zone but still valid, but the same thing can happen with any
caching server.

Brian

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 17 Jul 2001 05:35:15 -0700

>   2    Y   0  1 Secondary      Via AXFR, trustworthy only if AXFR is secure

why can the data be trusted just because the server read it from disk or
safely AXFRed? a lot of bad things could have happen to the data between
signing och loading, especially if you're doing off-line signing.

 - the signatures could have expired
 - the signatures could not be valid yet
 - someone could maliciously have inserted or altered data
 - data could be corrupted by other means

	jakob

---

From: Robert Elz <[email-masked]>
Date: Tue, 17 Jul 2001 05:38:10 -0700

Date:        Mon, 16 Jul 2001 16:43:44 -0700
    From:        Edward Lewis <[email-masked]>
    Message-ID:  <[email-masked]>

  | I am wondering if there is an unreported protocol problem in the
  | combination of TSIG, AD/AA, and AXFR.

This isn't  protocol problem, it is operational.   Using just the protocol
you have no way to determine the source of the data for AXFR at all, only
that it exists, and is being made available to you (and then the rules for
making sense of it all of course).

If you don't trust the server you're configured to obtain the data from to
send you accurate data, then you should be getting it from elsewhere.
All TSIG helps you do is rest assured that the data has truly been sent
to you from the server you configured to send it.

For anything more than this (knowing that the data is the correct data)
you really need to be using dnssec, and verifying all those signatures.

  | DNS Security is supposed to be about protecting the resolver,

But that's not what TSIG is about, I don't think (except when it is being
used to enable secure communications between a stub resolver and a back
end resolver/cache).

TSIG is just the cheap mechanism to get data that is secured via some other
means to a node that doesn't want to implement the full security model.
If the data wasn't already known to be secure, there's nothing TSIG can
possibly do to assist.

kre

---

From: "Scott Rose" <[email-masked]>
Date: Tue, 17 Jul 2001 06:10:40 -0700

Good question - I don't think there is any way (using the current DNSSEC
spec) for a stub resolver to know that the secondary is using a secure AXFR
other than knowing the policy out-of-band.

One possible solution would be to include a SIG generated by the primary
host along with the data (over the SOA).  This would be in addition to the
zone key SIG and only included when a secure AXFR is used.  However, then
the SIG must be verified by contacting the primary host (so we loose some of
the benefits of having secondaries since resolvers are still contacting the
primary).

As Brian said - it may not be that big of an issue.  Any malicious
alterations of zone data during a transfer will be noticed if the zone is
secured.  If it is unsecured to begin with, there are multiple points of
attack to worry about.  Is this a big enough problem to justify adding to
the spec?  I'm not so sure.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 17 Jul 2001 06:50:46 -0700

It is true DNSSEC can't guarantee that data is correct nor correctly
handled, but at least it will help point out where the fault is.  Perhaps
I've been assuming "trustworthy" with being able to trace the data back to
the (appropriate) source.

>From you message it sounds like no one should trust data with the AA bit,
as this means the authentication has not been checked.  This is an ironic
conclusion, as we've been assigning more credibility to AA'd data.  (Once
again, the credibility vs. authenticated issue arises.)

---

From: Edward Lewis <[email-masked]>
Date: Tue, 17 Jul 2001 06:50:38 -0700

>or maliciously altered, the recursive server will fail to verify it.

Yeah.  I am assuming that the "client" in this case isn't able to establish
a chain of trust (no code to do so or at least no configured key).  Perhaps
the "secondary" is also the "default/recursive" server for the client, or
that the client has a configured relationship with the authoritative
servers.

>longer in the zone but still valid, but the same thing can happen with any

If the client (I'll use that term) is relying on TSIG, they aren't likely
to do signature validation.  (Perhaps we should recommend that TSIG queries
be issued with the DNSSEC indication off.)

There is also the push to adopt TSIG ahead of signing zones.  I can see a
lot of zones using TSIG in limited runs well ahead of signing the zone - as
folks first see the benefit of TSIG, then see how hard it is to manage
secerts, and then discover the benefit of scaleable but more intensive
public key efforts.

---

From: Roy Arends <[email-masked]>
Date: Tue, 17 Jul 2001 07:50:44 -0700

> machine, so I think this asking about a secondary's source is valid.)

WRT axfr-clarify-02, situations 3 and 4 will not occur.

The problem is when some caching forwarder is also authoritative for a
local domain. Say that local domain is secured and applications using a
stub resolver (which forwards all to the local cache) depend on the AD
bit. The AD bit will never be set on responses containing local domain
data, since the queried server will never (!!!) check it.

If a server is willing to verify chains, why not verify the localy
configured data that happens to be in the chain, either verify data when
queried for it, or verify the data on accepting it (during disk-read,
axfr or caching).

Ofcourse having an authoritative and cache server in one might be not a
good setup, it is not strictly forbidden by a MUST NOT in any RFC.

What I'm actually saying is that there _is_ some indication that a
secondary trusts the transferred secure zone, by simply verifying the
received info, and set the AD bit on every query-response containing this
info.  In that, an axfr-response is just like any query-response in that
the response contents must be verified if possible.

Regards,

Roy

---

From: Edward Lewis <[email-masked]>
Date: Tue, 17 Jul 2001 08:14:54 -0700

If you are doing the chain validation, your queries should be issued with
no TSIG and the CD flag on, if you really want to optimize performance (in
the "good" case[0]).

[0] Meaning - optimizing for the situation when there is no attack on.  If
you are being flooded with maliciously inserted answers, then, yes, TSIG is
a good thing.

At 10:29 AM -0400 7/17/01, Roy Arends wrote:
>On Tue, 17 Jul 2001, Edward Lewis wrote:
>
>> (Perhaps we should recommend that TSIG queries be issued with the
>> DNSSEC indication off.)
>
>I think this is not a good idea.
>
>Since TSIG is server authentication (origin), DNSSEC is zone
>authentication (content) we could have the following situation:
>
>Say there is some application that wants to verify signatures itself (SSH
>KEY + SIG(KEY)), using the stub-resolver for queries, which is configured
>to TSIG all data from the caching forwarder. No DNSSEC response will then
>be received at the stub since the stub uses TSIG and the DO bit unset in
>your scenario.
>
>Roy Arends
>Nominum

---

From: Roy Arends <[email-masked]>
Date: Tue, 17 Jul 2001 08:14:23 -0700

Roy Arends
Nominum

---

From: Edward Lewis <[email-masked]>
Date: Tue, 17 Jul 2001 08:14:38 -0700

>WRT axfr-clarify-02, situations 3 and 4 will not occur.

Case 3 will occur - that's the "nominal case."  By "non-auth" I meant to
imply a recursive server that isn't authoritative for the answer.

>data, since the queried server will never (!!!) check it.

I think that relying on the AD bit alone is not sufficient.  A true
resolver should have logic that accepts AD or AA bit with TSIG as "as good
as I'm gonna get."  (This is why I want to know that the AXFR [if any]
wasn't vulnerable to a simple attack.)

>queried for it, or verify the data on accepting it (during disk-read,

The arguement against this is the time it takes.  But I would like to have
the option in some "strict policy" applications.

>good setup, it is not strictly forbidden by a MUST NOT in any RFC.

I wouldn't jump on the no-recursive on an authoritative bandwagon.  I think
it is reasonable to be authortitative and recurse for just the local stubs
(whether by physical interface or key).  Heck, I'd even be willing to acl
via (untrustworty) IP address in this instance.

>the response contents must be verified if possible.

I couldn't see .com's zone transfers working this way, but perhaps
super-secret.mil's transfers would like this.