Subject: Re: issues with draft-ietf-dnsext-dnssec-trans-00.txt

From: [email-masked] (Geoffrey Sisson)
Date: Mon, 14 Jun 2004 16:29:37 +0100 (BST)

Paul Vixie <[email-masked]> writes:

> (geoff, i'm not clear on how this proposal applies to NOERROR responses.)

Yes, this would likely not work properly if there were an owner name
match.  There would have to be an NSEC RR associated with every
authoritative owner name with a fictitious "Next Domain Field" entry.
Am I correct in thinking this is the essence of the "NSEC White Lies"
proposal in -trans?

> > > In short: with that solution, one could spoof responses to "deny
> > > everything" under co.uk., AUTHENTICATED existing names, signed and
> > > existing names, etc.
> > 
> > & how is that worse than the likely alternative of "do nothing"?
> 
> if you do nothing, then paranoid clients will continue to have very
> little confidence in spoofed data.  if you use a zone-covering NSEC
> for all responses, then paranoid clients will have high confidence
> in spoofed data.
> 
> not that i know of any paranoid clients, but we're all implicitly
> assuming that there will be some, or else we wouldn't be doing dnssec.
> 
> i do not think that "a zone-covering NSEC" should be listed in -trans
> as one of the alternatives.

Is "zone-covering NSEC" worse than "do-nothing"?  In "do-nothing",
NOERROR replies can be spoofed; with "zone-covering NSEC", only
NXDOMAIN replies could be spoofed, which seems to have substantially
less potential for damage.

[ I realise "Dynamic NSEC Synthesis" is another answer, but this may
require nearly as long to deploy as -ter. ]

Regards

Geoff

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Alex Bligh <[email-masked]>
Date: Mon, 14 Jun 2004 17:18:30 +0100

> for all responses, then paranoid clients will have high confidence

Which is one reason why it would be good if there was some signaling
that denials should not be treated as authenticated: as Peter Koch
suggests:

> This is difficult to answer as it depends on one's expectations. In "do
> nothing" we know it can happen, whereas in DNSSEC-bis we ``know'' it can't
> happen. That's why NSEC white lies needs an agreed upon signalling method
> which shouldn't need any new bits/flags.

even if only one particular form of zone-covering NSEC record, e.g.
	\001	IN	NSEC	\001

Alex