Subject: [dnsext] one algorithm number or two

From: Edward Lewis <[email-masked]>
Date: Thu, 11 Dec 2008 14:40:17 -0500

The issue of whether to assign just one algorithm number or two 
algorithm numbers for RSA/SHA-2 is a result of there being no unified 
DNS definition.  I.e., you can't assume a DNS server fully implements 
RFC 1995, even if it is used to host the global public Internet's 
root zone.  The situation is not unique to this draft.

The document describing RSA/SHA-2 could elect to assign one number 
provided the specification require (MUST) compliance with RFC 5011 in 
all implementations (compliant with the new hash).

But my preference is not to tie RSA/SHA-1 to NSEC3.  It's known that 
I have been skeptical of NSEC3, to the irritation of a few people. 
There's no need to go into that again, not now and not here.  Whether 
my skepticism is warranted or not, I feel that NSEC3 is still too 
immature to assume that it is an essential core element of DNS or 
DNSSEC.

I know a lot of TLDs are planning on NSEC3.  But as of today, none 
are publishing their production zones with NSEC3 records.  Maybe they 
soon will, but I'm too old school to bet on the future.

I don't like having two separate algorithm numbers.  It makes more 
sense to use the one algorithm number route.

But I think having two numbers is a safer bet on the future.  Perhaps 
if NSEC3 has a proven track record, we can get by with assigning just 
one number.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Never confuse activity with progress.  Activity pays more.

--
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: Andrew Sullivan <[email-masked]>
Date: Thu, 11 Dec 2008 15:13:00 -0500

On Thu, Dec 11, 2008 at 02:40:17PM -0500, Edward Lewis wrote:

> But my preference is not to tie RSA/SHA-1 to NSEC3.  It's known that I 
> have been skeptical of NSEC3, to the irritation of a few people. There's 
> no need to go into that again, not now and not here.  Whether my 
> skepticism is warranted or not, I feel that NSEC3 is still too immature 
> to assume that it is an essential core element of DNS or DNSSEC.

Does the above constitute an objection to the direction we've lately
apparently been headed, which was to revert to one identifier?  That
is, you seem to be arguing against one identifier, and in favour of
two.  How strongly do you feel about it?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 11 Dec 2008 15:41:00 -0500

>two.  How strongly do you feel about it?

Against all sensibility, I think the wiser course is to use a second 
number again.

I don't like the precedent (either) - that is, using one algorithm 
number per crypto algorithm/hash per version of negative answer in 
play - I mean when NSEC5 is out there, will we be assigning three per 
algorithm?

I think until NSEC3 has an operational resume behind it can we start 
writing (non-negative answer) specs that assume NSEC3's 
implementation.  The lack of experience (or that multiple proven 
interoperable full-release-level implementations exist) is why I lean 
to sticking with two numbers still.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Mark Andrews <[email-masked]>
Date: Fri, 12 Dec 2008 08:59:00 +1100

> if NSEC3 has a proven track record, we can get by with assigning just 

	We can always go back and assign a NSEC only alias later
	if we end up seeing operational problems with the single
	assignment.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Thu, 11 Dec 2008 18:11:19 -0500

>	if we end up seeing operational problems with the single

I have a hard time imagining the IETF effectively responding to an 
operational problem in a timely fashion.

The question is, how confident are we that NSEC3 is "perfect" and 
will not be supplanted by something else, in the same manner that 
NSEC3 has supplanted NSEC (in many people's eyes)?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Mark Andrews <[email-masked]>
Date: Fri, 12 Dec 2008 10:40:38 +1100

> NSEC3 has supplanted NSEC (in many people's eyes)?

	Ed, validators essentially have to accept what zone operators
	sign with.  Having a second number for NSEC only does not
	change that.  If there is a problem with NSEC3 then we need
	to tell people to sign with NSEC.  Having a second number
	does not change that.  Having a single number doesn't prevent
	zone operators from signing using NSEC.

	Mark

---

From: Alex Bligh <[email-masked]>
Date: Fri, 12 Dec 2008 10:34:39 +0000

> operational problem in a timely fashion.

I have a hard time working out what kind of operational problem
would require such action. Presumably a serious NSEC3 protocol
flaw that made it less usable than NSEC3 (i.e. not merely
in its non-enumerability qualities), COMBINED WITH an operational
requirement to move to rsasha256. If there is a realistic possibility
this might occur in a timescale quicker than it takes IETF to
allocate an algorithm number, why aren't we making rsasha256 support
mandatory anyway?

> The question is, how confident are we that NSEC3 is "perfect" and will
> not be supplanted by something else, in the same manner that NSEC3 has
> supplanted NSEC (in many people's eyes)?

No, I don't think that is the question. If NSEC3 is supplanted by something
else, we would presumably need signalling of that for all algorithms.
I think the question is "how confident are we that NSEC3 will not
be supplanted by NSEC" as it's only NSEC to which it is being proposed
that no algorithm number be allocated.

Alex

---

From: Peter Koch <[email-masked]>
Date: Fri, 12 Dec 2008 15:33:55 +0100

> NSEC3 has supplanted NSEC (in many people's eyes)?

Ed, I don't think this is a fair question. As we've learned the signalling of
NSEC3 in RFC 5155 actually means that either NSEC or NSEC3 could be used
within the zone.  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. An NSEC3-aware validator
will find its way. Of course, there could be a third flavor that recognizes
the signalling and the NSEC3 RR, but doesn't implement NSEC3 validation.

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.
The one thing that is asked is that the resolver recognize the NSEC3 RR type.
The detail that needs to be hashed out, though, is how much "recognition"
is necessary.  Is it sufficient to have "a" (validated) NSEC3 RR in the response
to conclude that there's not going to be an NSEC RR (so as to prove the
NSEC RR(s) ha{s,ve}n't been stripped of) or does the validator actually have
to do the hashing -- which would probably half way of implementing NSEC3
already?

This is independent of general deployment and independent of the actual use
of NSEC3 in a particular zone.  I'd assume there will be a number of zones
where NSEC3 doesn't buy much and which will continue to use NSEC anyway.

-Peter

---

From: Samuel Weiler <[email-masked]>
Date: Fri, 12 Dec 2008 12:08:08 -0500 (EST)

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

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.  The base specs routinely talk about the zone security status.

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

-- Sam

---

From: Mark Andrews <[email-masked]>
Date: Sat, 13 Dec 2008 10:06:03 +1100

In message <[email-masked]>, Samuel Weil
er writes:
> 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 

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

	Rubbish.

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

	And that still stands.
 
> this out as a difference from the base specs.  (RFC4035 section 4.3 

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

	Mark