Subject: Re: base32 alphabet rant - rhaaaaa rfc3548

From: Peter Koch <[email-masked]>
Date: Mon, 24 Oct 2005 13:32:18 +0200

Ben Laurie wrote:

> It could? How? Are you suggesting that different label types are somehow
> in different spaces?

Roy Arends wrote:

> Does it matter wrt the paradox problem if a label exists at labeltype 00 
> or labeltype 0100002 ?

New label types extend the alphabet available for labels and by doing so
extend the namespace. "New" labels do not belong to the classic namespace.

Section 6.1 of RFC 4034 does only define sort order for old style labels.
Bitstring labels (RFC 2673) hook themselves into the namespace by explicitly
specifying their relation to "canonical sort order".

> Canonical ordering for NSEC doesn't account for 8-bit data...

Right, so if we do not define any sort order for this new label type,
it cannot be secured by NSEC RRs, but that's not a problem. We don't
even need to prohibit those labels to own anything but NSEC, since
anybody tempted should "know what they are doing". The new namespace
extension would be contiguous and separate from the old space and would
not interfere with it. That's different from what real and rational
numbers do in mathematics :-)

However, the new label type might add some complexity which would need
very careful consideration.

-Peter

--
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: bert hubert <[email-masked]>
Date: Mon, 24 Oct 2005 13:56:20 +0200

> extend the namespace. "New" labels do not belong to the classic namespace.

Be aware btw that adding whole new label types (again) raises the bar
significantly for adoption of NSEC3 and hence DNSSEC.

I politely disagree with Paul V when he says that adding a label type is not
harder than adding another record, it is way more fundamental.

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: Ben Laurie <[email-masked]>
Date: Mon, 24 Oct 2005 15:26:52 +0100

> very careful consideration.

Don't we have enough careful consideration already?

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Roy Arends <[email-masked]>
Date: Mon, 24 Oct 2005 16:56:43 +0200 (CEST)

> extend the namespace. "New" labels do not belong to the classic namespace.

Is there any specific section in rfc4033/4/5 that restricts using DNSSEC 
to prove absence/presence of records with extended label types in its 
ownername ?

> specifying their relation to "canonical sort order".

True but non-sequitur.

Your point was:

''this could also elegantly solve the "paradox problem", where the NSEC3 
chain denies its owners' existance.''

Where ''this'' refered to using an extended label type for 8 bit labels.

> it cannot be secured by NSEC RRs, but that's not a problem.

Indeed. One would need to define sort-order for 8 bit labels for the 
purpose of dnssec.

> We don't even need to prohibit those labels to own anything but NSEC, 
> since anybody tempted should "know what they are doing". The new 
> namespace extension would be contiguous and separate from the old space 
> and would not interfere with it. That's different from what real and 
> rational numbers do in mathematics :-)

This still doesn't convince me that 8bit labels offer a solution to the 
paradox problem.

On one end, if 8 bit labels were for NSEC3 only, sure, there is no point 
in NSEC3 acknowledging the existence of itself, and hence, declare this 
special label type outside the 'provable existent namespace'.

On the other end, if 8 bit labels can be used by anything, we'd need to be 
able to prove their existence/absence, and there we have the paradox 
problem again.

> very careful consideration.

I don't think the 'paradox problem' is a real issue.

Roy

---

From: Paul Vixie <[email-masked]>
Date: Mon, 24 Oct 2005 16:33:20 +0000

# Be aware btw that adding whole new label types (again) raises the bar
# significantly for adoption of NSEC3 and hence DNSSEC.

deployment difficulty is first a function of the number of protocol agents you
have to upgrade, ans second the complexity of the protocol or software itself.

as far as i can tell, no existing middlebox will tolerate NSEC3.

# I politely disagree with Paul V when he says that adding a label type is not
# harder than adding another record, it is way more fundamental.

i didn't say records, i said edns elements.  rolling out a new label type is
not going to be harder than rolling out the OPT RR was, and probably easier.

---

From: David Blacka <[email-masked]>
Date: Mon, 24 Oct 2005 12:58:50 -0400

> as far as i can tell, no existing middlebox will tolerate NSEC3.

What do you mean by "tolerate"?  It seems to me that, while  
validating through an NSEC3-unaware middlebox is not likely to work,  
the answer itself should get through.

> not going to be harder than rolling out the OPT RR was, and  

What happens when pre-EDNS0 DNS software sees an extended label type?
What happens when post-ENDS0 softwares sees an unknown extended label  
type?

--
David Blacka    <[email-masked]>
Sr. Engineer    VeriSign Applied Research

---

From: Alex Bligh <[email-masked]>
Date: Mon, 24 Oct 2005 18:04:26 +0100

> as far as i can tell, no existing middlebox will tolerate NSEC3.

Really? All middleboxen filter out all RRs they do not fully understand, no
matter what the purpose of said middleboxen are? That's a surprising
statement.

Alex

---

From: Mike StJohns <[email-masked]>
Date: Mon, 24 Oct 2005 13:14:00 -0400

>not going to be harder than rolling out the OPT RR was, and probably easier.

My turn to politely disagree.  OPT RRs are still RRs are are ignored by 
non-compliant (hmm... to clarify  I mean resolvers that don't understand 
OPT) resolvers.   A label type that is neither 0 (normal) nor 3 (pointer) 
will probably return BADLABELTYPE in most resolvers and halt processing of 
the entire message.   Which suggests that this could only be sent to a 
resolver that explicitly indicates it understands the new label type(s).

So I think you're talking changes to either the OPT RR or something else in 
addition to whatever other changes if you add a new label type.  Are there 
also master file format changes to indicate the new label type?  *yuck*

---

From: Paul Vixie <[email-masked]>
Date: Mon, 24 Oct 2005 17:14:41 +0000

# > as far as i can tell, no existing middlebox will tolerate NSEC3.
# 
# What do you mean by "tolerate"?  It seems to me that, while  validating
# through an NSEC3-unaware middlebox is not likely to work,  the answer
# itself should get through.

your explaination is better.  what i meant was, there will be a sea-to-sea
upgrade to get NSEC3 in place.  if we're going to touch that many agents,
can we please pay in advance for what we want instead of paying in arrears
for what we needed?

# What happens when pre-EDNS0 DNS software sees an extended label type?

it won't, since it will not do the EDNS negotiation, and this element will
not be usable in messages to such agents.

# What happens when post-ENDS0 softwares sees an unknown extended label type?

again, it won't.  this would be a new element whose structure is not known
by EDNS0 agents, and so it would require a version number increment.  (unlike
flags, whose structure is known but whose meaning is not... with a flag, you
only have to increment the version number if "ignored by older agents" is not
acceptable to the flag-designer.)

---

From: Paul Vixie <[email-masked]>
Date: Mon, 24 Oct 2005 17:24:15 +0000

# >i didn't say records, i said edns elements.  rolling out a new label type
# >is not going to be harder than rolling out the OPT RR was, and probably
# >easier.
# 
# My turn to politely disagree.  OPT RRs are still RRs are are ignored by
# non-compliant (hmm... to clarify  I mean resolvers that don't understand
# OPT) resolvers.

OPT will never be seen in a response by an agent who did not solicit them,
and an ignored initiatory OPT just means "EDNS negotiation failed."

# A label type that is neither 0 (normal) nor 3 (pointer) will probably return
# BADLABELTYPE in most resolvers and halt processing of the entire message.
# Which suggests that this could only be sent to a resolver that explicitly
# indicates it understands the new label type(s).

it's all about solicitation.

# So I think you're talking changes to either the OPT RR or something else in
# addition to whatever other changes if you add a new label type.  Are there
# also master file format changes to indicate the new label type?  *yuck*

yes.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 24 Oct 2005 17:20:44 +0000

# > as far as i can tell, no existing middlebox will tolerate NSEC3.
# 
# Really? All middleboxen filter out all RRs they do not fully understand, no
# matter what the purpose of said middleboxen are? That's a surprising
# statement.

assuming that the middlebox ends up receiving and caching an NSEC3, it will
not include it in regenerated forwarded responses, nor in responses from
cache.  NSEC3 agents behind pre-NSEC3 middleboxes will have to make a third
query to fetch the NSEC3, based on bits they see in the zone apex data, 
which they'll have had to make a second query to see, since it wouldn't've
been included earlier either.

it's interesting that folks complain about how DLV makes an extra query :-).

---

From: David Blacka <[email-masked]>
Date: Mon, 24 Oct 2005 14:12:24 -0400

> been included earlier either.

What bits in the zone apex data?  What are you talking about?

In general, validation through a non-<blah>-aware middlebox doesn't  
work, for RFC 4035 DNSSEC or NSEC3.  The validator isn't going to  
make extra queries for the missing NSEC/NSEC3's, because, in a number  
of cases, it won't know what qname to use.  In RFC 4035 this occurs  
for rcode=3.  In NSEC3, this is true for NOERROR/NODATA responses as  
well.

> it's interesting that folks complain about how DLV makes an extra  

NSEC3 doesn't introduce extra queries AFAICT.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 24 Oct 2005 18:15:45 +0000

# In general, validation through a non-<blah>-aware middlebox doesn't  work,
# for RFC 4035 DNSSEC or NSEC3.  The validator isn't going to  make extra
# queries for the missing NSEC/NSEC3's, because, in a number  of cases, it
# won't know what qname to use.  In RFC 4035 this occurs  for rcode=3.  In
# NSEC3, this is true for NOERROR/NODATA responses as  well.

so, NSEC3 will be a sea-to-sea change, and NSEC-aware middleboxes will have
to be upgraded, not just authority servers and query-initiating "clients"?

---

From: David Blacka <[email-masked]>
Date: Mon, 24 Oct 2005 14:16:16 -0400

> acceptable to the flag-designer.)

I see.  Adding an extended label type implies increasing the EDNS  
version.  This wasn't clear to me.  It doesn't seem to be stated one  
way or another in RFC 2671.

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 24 Oct 2005 21:57:21 +0200

On Oct 24, 2005, at 19:20 , Paul Vixie wrote:

>  NSEC3 agents behind pre-NSEC3 middleboxes will have to make a third

Huh?

How will these client  know the QNAME, QTYPE, [QCLASS] at which to  
find that NSEC3 record???

Its worse than with DNSSECbis.. You will never know where to find a  
missing NSEC3 (I think).

--Olaf
-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/