Re: [dnsext] one algorithm number or two

[Mark Andrews <Mark_Andrews@isc.org>]

In message <alpine.BSF.1.10.0812121138370.65532@fledge.watson.org>, Samuel Weil
er writes:
> On Fri, 12 Dec 2008, Peter Koch wrote:
> 
> > ... So, the resolver doesn't know in advance which method it will 
> > see, it is just told to expect either one.  An NSEC3-agnostic 
> > validator will likely treat the zone as insecure.
> ...
> > The same holds for the sha256 aware validator, except that it won't 
> > know for sure in advance to treat the zone as insecure if it doesn't 
> > implement NSEC3.
> 
> Indeed, it won't be able to make any determination about the _zone_ 
> status at all, only about the status of particular answers.

	The zone status is that is signed using the methods (plural)
	signaled by the algorithm number.

> An 
> NSEC3-agnostic resolver might well get positive answers from the NSEC3 
> zone and treat them as secure long before it sees a negative answere 
> which it must treat as unsigned.  Part of the zone appears secure, 
> part unsigned.

	Stop talking rubbish.  A validator either FULLY understands
	what a alogorithm number requires or it treats the zone as
	insecure.  This is why we choose aliases 5 to 7 because there
	were validators deployed that understood what 5 meant.

	There are no validators that understand what TBA means.  We
	have a green field with SHA256.
 
> I'm having trouble thinking of another example of a validator not 
> being able to make a "zone" status determination by examining the zone 
> cut.

	Rubbish.

> The base specs routinely talk about the zone security status.

	And that still stands.
 
> Does it matter?  Probably not.  But it's the same sort of apparently 
> academic difference that "DS is the first RR to appear only on the 
> parent's side of a delegation" was.  We thought that difference didn't 
> matter.  RFC4035 section 3.1.4.1 was the result.  Maybe using two 
> (four) algorithm numbers is the right path for now.
> 
> If we don't leave both algorithm numbers, Jelte's text needs to be 
> modified to specify "answers", not "zones", and should explicitly call 
> this out as a difference from the base specs.  (RFC4035 section 4.3 
> et. al.)

	You just need to stop thinking "signed using NSEC" vs "signed
	using NSEC3" is what is being signalled because it isn't.

	Mark
> 
> -- Sam
> 
> --
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/namedroppers/>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews@isc.org

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