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

From: Brian Wellington <[email-masked]>
Date: Mon, 30 Jul 2001 11:26:06 -0700

On Mon, 30 Jul 2001, Jakob Schlyter wrote:

> On Sun, 29 Jul 2001, Brian Wellington wrote:
>
> > > 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.
>
> the stub resolver may care whether the server has validated the data or
> not. if the servers hasn't validated the data, e.g. data data was never
> protected by dnssec, it can choose not to trust it at all.

Please reread the preceding paragraph, and the argument I've been making
for the past week.  The server should be able to avoid validating the data
because it implicitly trusts the data.  The stub resolver shouldn't care
why the server trusts it; it should just care that it does.  If it doesn't
trust the server to properly set the AD on implicitly trusted data, it
shouldn't believe the AD bit at all.

> > 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.
>
> the "only" disagreement here is whether you may set AD without doing any
> cryptographic validation - on load (and checking for expired signatures on
> reply) or on reply.

Right.

> I'd like a "MUST NOT set the AD bit without cryptographic validation", but
> could go for a "SHOULD NOT" if that's the consensus of the WG. something
> less stronger is to weak I believe.

And I'd like the draft to stay as it is.  I'll note (yet again) that it
currently allows both the policy that I'm advocating and the policy that
you're advocating.

> how do we resolve this? it would be nice if we could continue to secure
> the world instead of debating bits the headers :-)

The draft has already been through last call several times, and has had
only minor clarifications.  It might have progressed along the standards
process if people weren't trying to fundamentally change it now.

Brian

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