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

[Brian Wellington <[e-mail]>]

On Sun, 29 Jul 2001, Jakob Schlyter wrote:

> On Sat, 28 Jul 2001, Edward Lewis wrote:
>
> > IMHO an AA bit outranks an AD bit.  Data with AA=1,AD=0 is reputedly
> > coming from *the* source (TSIG, et.al.)  Data with AA=0,AD=1 is
> > reputedly data that some intermediary has verified as coming from the
> > source.  I would assign higher credibility to AA=1,AD=0 than
> > AA=0,AD=1.
>
> an application could put trust in a dns reply by several reasons:
>
> 	reply source (i.e. who did I query)
> 	reply transport (i.e. tsig, tkey or nothing)
> 	status of some bits in the header (AA, AD, ...)
>
> I have to configure who and how I send my query, so this is a very basic
> administrative problem (except for the policy part, but let's leave that
> out for the moment). the AD-bit however is harder and needs to be well
> defined as applications will interpret it without knowing the verification
> policy.

I agree so far.

> the reason I like the nameserver to use the AD-bit, and only the AD-bit,
> to signal that the data is authenticated cryptographically is simplicity.
> I do not care about whether my nameserver is authorative or not - I only
> care if it has validated the data or not. it could be authorative, yet the
> zonefile could be invalid (e.g. the nameserver is secondary and doesn't
> fully trust source).

This is the problem.  The stub resolver should not care whether the server
has validated the data or not.  If the resolver trusts the server, the
server trusts the data, and the communication is secure, the resolver
should trust the data.

Let me give an example.  I have a server that's authoritative for foo.com,
which is signed.  It also does recursion for my network.  Assume that
my resolver communicate securely with this server, and I trust it.

If I query for bar.com, which is also signed, the server recursively
fetches data data, does the validation, and returns a response with AD
set.  The resolver sees the AD bit, so it trusts the data.  No one's
arguing about this.

If I query for foo.com, I would like to be able to trust the answer
without having cryptographic validation done.  I trust the server, and the
communication, so I can trust the data.  I'm arguing that it's ok to allow
the server to set the AD bit on locally configured secure data.  Ed said
that the server shouldn't set the AD bit, but the resolver could trust
data with the AA bit.  You're saying that the resolver shouldn't trust
this data at all unless cryptographic verification is done.

This only comes up when querying a server for authoritative data.  The
only time stub resolvers query authoritative servers is for locally
managed data.  The resolver should be allowed to trust locally managed
data.  This is not about protecting the resolver from arbitrary broken
servers; it's about allowing resolvers to trust local servers without
forcing them to explicitly verify data.

> let us, for the people using this - not the implementators, keep this
> simple. finding something to trust and communicate securely with that
> entity is hard enough.

The above is from the point of view of a user.  I'd like to be able to
sign my zone at home and use DNSSEC capable applications (like a modified
SSH), without forcing my server to needlessly verify data that it either
loads from disk or obtains through a secure zone transfer.

Brian



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