Subject: base32 alphabet rant - rhaaaaa rfc3548

From: Roy Arends <[email-masked]>
Date: Thu, 20 Oct 2005 23:50:48 +0200

There exist multiple base32 alphabets. The two mostly used are
"A-Z2-7" (examples in rfc3548) and "0-9A-V" (examples in rfc2938).

The problem with "A-Z2-7" is that the sort order of a set of binary values
is different than the sort order of its base32 equivalent in ascii order.

As an example, it is obvious that 1091 is lower than 26624. However, if
one would sort the base32 representations in ascii order (1091="BCD" and
26624= "2AA") then 2AA is lower than BCD.

In NSEC3, owner names contain base32 encodings of binary hash values,
while the 'next hashed owner name' contains a binary hash value.  After
adding NSEC3 and before signing, the set of NSEC3s is sorted in 'canonical
order'. When a validating resolver validates (for instance) an NXDOMAIN
response, it compares the hashed QNAME with the two values in the NSEC3
record. In all these things, order is important.

To end this ordering problem, we're not going to use the base32 alphabet
"A-Z2-7" explained in rfc3548, but use the "0-9A-V" alphabet that is
explained in for instance rfc2938.

Note that rfc3548 is informational, and that it refers to the origin of
this base32 alphabet on a work in progress. However, this work in progress
does not mention any base32 encoding. RFC3548 also refers to rfc2938, but
this rfc is using the "0-9A-V" alphabet.

I'll prolly add a section on this base "0-9A-V" alphabet. Something I
hoped wasn't necessary, but since the sort order is screwed, I have to.

Roy

--
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: Simon Josefsson <[email-masked]>
Date: Sat, 22 Oct 2005 14:47:13 +0200

> "A-Z2-7" (examples in rfc3548) and "0-9A-V" (examples in rfc2938).

We could update RFC 3548 to add an alternative base32 alphabet, to
handle this problem.  I have some other pending nits to that document,
available from <http://josefsson.org/base-encoding/>.

> does not mention any base32 encoding.

Look at the 00..02 versions of that draft; it was agreed by the SASL
WG to split out the part that uses base32 into a separate document,
but that document hasn't materialized itself yet.  I may convince them
to use the 0-9A-V alphabet instead.

> hoped wasn't necessary, but since the sort order is screwed, I have to.

I agree.

Regards,
Simon

---

From: Paul Vixie <[email-masked]>
Date: Sat, 22 Oct 2005 14:42:06 +0000

# > There exist multiple base32 alphabets. The two mostly used are
# > "A-Z2-7" (examples in rfc3548) and "0-9A-V" (examples in rfc2938).
# 
# We could update RFC 3548 to add an alternative base32 alphabet, to
# handle this problem.  I have some other pending nits to that document,
# available from <http://josefsson.org/base-encoding/>.

i think the presentation encoding doesn't matter much.  ordering should be by
network encoding, not by the presentation encoding.  the fact that
presentation and network encoding yield different orders is ugly but nonfatal.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 22 Oct 2005 16:02:47 +0100

> presentation and network encoding yield different orders is ugly but nonfatal.

This is the network encoding, not the presentation encoding.

Cheers,

Ben.

-- 
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: Simon Josefsson <[email-masked]>
Date: Sat, 22 Oct 2005 17:45:16 +0200

> presentation and network encoding yield different orders is ugly but nonfatal.

This is the network encoding, since it is the owner name that is
base32 encoded.  Resolvers can't be expected to base32 decode NSEC3
owner names before canonical ordering.

However, is the complexity induced by base32 needed?  In my NO
proposal, which is pretty much the same as NSEC3, I referenced the
base-n document but for the base-16 encoding.  That is, I used the hex
encoding, resulting in records such as:

   1b7838c69a66eb50cc215f66ee4554d0c4c940a5
   		IN NO A 0x222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1
   222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1
   		IN NO NS SOA MX 0x839ebd4386c0b26d81f147421b5b7036e61438cf
   839ebd4386c0b26d81f147421b5b7036e61438cf
   		IN NO A 0x906a0ad5e604b1905828499dc8672ecb8de73e2f

Regards,
Simon

---

From: Paul Vixie <[email-masked]>
Date: Sat, 22 Oct 2005 16:46:37 +0000

# This is the network encoding, since it is the owner name that is
# base32 encoded.  Resolvers can't be expected to base32 decode NSEC3
# owner names before canonical ordering.

ah.

# However, is the complexity induced by base32 needed?  In my NO
# proposal, which is pretty much the same as NSEC3, I referenced the
# base-n document but for the base-16 encoding.  That is, I used the hex
# encoding, resulting in records such as:
# 
#    1b7838c69a66eb50cc215f66ee4554d0c4c940a5
#    		IN NO A 0x222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1
#    222c7a74bc40e818aa53b3eb0b15cd2350fbb3a1
#    		IN NO NS SOA MX 0x839ebd4386c0b26d81f147421b5b7036e61438cf
#    839ebd4386c0b26d81f147421b5b7036e61438cf
#    		IN NO A 0x906a0ad5e604b1905828499dc8672ecb8de73e2f

while i was a fan of the NO RR, none of these encodings are wonderful.

ideally we would allocate an extended label type that said "it's 8-bit
binary data, without case folding" and the presentation format for it
would be the similar to what we use for unknown RR types, or bitstring
labels.

putting the complexity of "avoid case folding, and only use printable
characters" into the wire encoding of what is essentially binary data
is really doing everything the long way.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 22 Oct 2005 19:09:47 +0200

> would be the similar to what we use for unknown RR types, or bitstring

Do we know that introducing a new label type work?  Adding a new label
type sounds like plenty of work, complexity and risk to me.  I believe
it would be detrimental to the deployment of NSEC3 to conflate it with
the use of a new label type.  Using a new label type was suggested for
NO too, and was dropped back then due to similar concerns too.

> is really doing everything the long way.

Not really.  Without positive feedback from deployment experiments
with extended label types, using owner names that are hex (or base32)
encoded sounds more practical to me.

Regards,
Simon

---

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

# Do we know that introducing a new label type work?  Adding a new label
# type sounds like plenty of work, complexity and risk to me.

any protocol agent that has to be upgraded to understand NSEC3 can be
upgraded to understand any other new element, like a new extended label
type, at the same time.

# ... Without positive feedback from deployment experiments with extended
# label types, using owner names that are hex (or base32) encoded sounds
# more practical to me.

it was the intent of RFC 2671 to make it possible to do the right thing.
the feedback from other features to date that were based on 2671 encodings
has been positive.  i have no reason to think a new extended label type
will pose any special challenge.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 22 Oct 2005 20:03:38 +0200

> upgraded to understand any other new element, like a new extended label

Of course.  I was talking about what was practical to do.

Pro:
  ?

Con:
  The work and added complexity involved to define a new extended label type.

Occam's razor...

> will pose any special challenge.

Has any extended label types been defined?

I can't even find the IANA registry for EDNS Label Type's.  Presumably
because nobody has done any serious work with extended label types.

I think an extended label type would involve plenty of extra work for
the NSEC3 authors, which would slow their effort down, with no
apparent gain.

Regards,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 22 Oct 2005 20:24:35 +0200

Roy Arends <[email-masked]> writes:

> Is the pending-nits combined with a second alphabet for base32 
> substantional enough to justify 3548-bis ?

We only find out if we try.

> Would be nice since a normative reference is more handsome than
> adding yet another appendix explaining base32.

Agreed.  Getting rid of incompatible base-n descriptions was the goal
of the document.

The cut-off date for initial drafts has passed, but I'll submit
draft-josefsson-rfc3548bis-00 after the IETF meeting.  As always, the
live document can be found at <http://josefsson.org/base-encoding/>,
and I invite comments and suggestions.  I haven't added the base32
0-9A-V alphabet yet, though.

Cheers,
Simon

---

From: Paul Vixie <[email-masked]>
Date: Sat, 22 Oct 2005 19:15:43 +0000

# Pro:
#   ?
# 
# Con:
#   The work and added complexity involved to define a new extended label type.
# 
# Occam's razor...

that's a little quick on the draw, don't you think?

the pro is, we keep wanting non-case-folder non-printable labels, and we keep
inventing ways to encode them.  base32 is an inefficient way to do this, it
means some bits on the wire are meaningless constants (MBZ/MB1).  for that
matter the IDN encoding is an inefficient way to do this.  sooner or later we
ought to allocate a label type that does what we want.  why not now?  (i'll
help!)

# Has any extended label types been defined?

only the metameta (to allow for future expansion beyond the current extended
labels.)

# I can't even find the IANA registry for EDNS Label Type's.  Presumably
# because nobody has done any serious work with extended label types.

i don't think that's a reason to say they aren't or can't be useful.  any
time we're proposing to change all participating protocol agents we have to
think about piggybacking other changes.  like DNSSEC ended up depending on
EDNS due to packet size and option issues.  an NSEC3 that depends on a new
label type is "no big deal".

# I think an extended label type would involve plenty of extra work for the
# NSEC3 authors, which would slow their effort down, with no apparent gain.

if the NSEC3 authors were working alone, or with a blank slate, that would
matter.  but deploying NSEC3 is a burden and benefit to a much larger
community, and that community has a say as to what ought to be piggybacked.

i dearly wish that i had included binary-octet (non-bitstring binary) label
types in the EDNS0 draft.  i think that when i split things off into EDNS1,
i cut too deep.  IDN needed this.  NSEC3 now needs it.  if i write it up,
would anyone (other than simon, apparently) agree to make NSEC3 dependent
on it?

---

From: Simon Josefsson <[email-masked]>
Date: Sun, 23 Oct 2005 00:58:52 +0200

Roy Arends <[email-masked]> writes:

> On Sat, 22 Oct 2005, Simon Josefsson wrote:
>
> Lets try.

I have added the 0-9A-V base32 alphabet to
draft-josefsson-rfc3548bis-00, which is available from:

<http://josefsson.org/base-encoding/>

I would appreciate to hear about other problems with that document.  I
will submit the document when the I-D editor re-opens after the
meeting.  Perhaps the document could advance together with NSEC3, if
you chose to use the base32 encoding, that is.  Perhaps we could even
push rfc3548bis onto the standards track; the document is used as a
normative reference by a few standards.

I'll check with the SASL WG if they wish to continue using the A-Z2-7
alphabet for the GSS-API mechanism document.  If not, I think we
should make the 0-9A-V alphabet the default alphabet.  The A-Z2-7
alphabet could then be the non-canonical "special" alphabet, compare
the situation for base64.  The A-Z2-7 alphabet reduces mistakes when
the base32 data is entered by humans (0 can be confused with O and 1
with I and l), so there are some merit to it.

Cheers,
Simon

---

From: Roy Arends <[email-masked]>
Date: Sat, 22 Oct 2005 19:59:02 +0200 (W. Europe Daylight Time)

> available from <http://josefsson.org/base-encoding/>.

That would be a good thing.

> to use the 0-9A-V alphabet instead.

That would be a good thing too.

Is the pending-nits combined with a second alphabet for base32 
substantional enough to justify 3548-bis ? Would be nice since a normative 
reference is more handsome than adding yet another appendix explaining 
base32.

Thanks,

Roy

---

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

It took me a while to crock why the owner names are not in binary  
encoded format and why we need the encoding wizardry for the owner  
names.

> would be the similar to what we use for unknown RR types, or bitstring

It might be wise to add a paragraph to explain that the  
representation format of the owner name is chosen so it survives case  
folding.

--Olaf
    namedropper.

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

---

From: Peter Koch <[email-masked]>
Date: Mon, 24 Oct 2005 09:55:23 +0200

> would be the similar to what we use for unknown RR types, or bitstring

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

-Peter

---

From: Roy Arends <[email-masked]>
Date: Mon, 24 Oct 2005 10:07:42 +0200 (CEST)

On Mon, 24 Oct 2005, Olaf M. Kolkman wrote:

> It took me a while to crock why the owner names are not in binary encoded 
> format and why we need the encoding wizardry for the owner names.
>
> Paul's remark helped:
>
> It might be wise to add a paragraph to explain that the representation format 
> of the owner name is chosen so it survives case folding.

Good point, will add, though we just submitted version -03 of the nsec3 
draft.

Roy

---

From: Roy Arends <[email-masked]>
Date: Mon, 24 Oct 2005 10:17:54 +0200 (CEST)

> denies its owners' existance.

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

Roy

---

From: Ben Laurie <[email-masked]>
Date: Mon, 24 Oct 2005 11:29:58 +0100

> denies its owners' existance. 

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

Hmm. Now here's a fun problem. If an 8-bit label type is introduced and
used for anything other than NSEC3, then how does it work with NSEC?
Canonical ordering for NSEC doesn't account for 8-bit data...

Cheers,

Ben.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 24 Oct 2005 11:30:27 +0100

Roy Arends wrote:
>> encoded format and why we need the encoding wizardry for the owner names.
>>
>> Paul's remark helped:
>>
>> It might be wise to add a paragraph to explain that the representation
>> format of the owner name is chosen so it survives case folding.
> 

You have 1.5 hours to submit -04 :-)

---

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

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

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

---

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: Chris Thompson <[email-masked]>
Date: Mon, 24 Oct 2005 13:12:35 +0100 (BST)

Olaf Kolkman writes:

[...]
> representation format of the owner name is chosen so it survives case  

As a reductio ad absurdum of this whole thread, perhaps it should be
pointed out that we could avoid those pesky liable-to-case-folding
letters altogether, without using binary labels. There are 34 other
printable ASCII characters that can occur in labels in master files
without having to be quoted:

  !#%&'*+,-/0123456789:<=>?@[]^_`{|}

* and @ have special meanings only when they occur in isolation, but
we can even drop those and retain enough for a base32 encoding ...

-- 
Chris Thompson
Email: [email-masked]

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 24 Oct 2005 15:44:33 +0200

> that's a little quick on the draw, don't you think?

Well, we are still discussing the matter.

> ought to allocate a label type that does what we want.  why not now?  (i'll

I don't see justification of why NSEC3 should use an extended label
type here.

I only see justification of why a document that describe binary label
type would be a good idea.  I think such a document may be useful.  If
that effort was successful, future RRs may utilize it.

> label type is "no big deal".

I disagree.

> community, and that community has a say as to what ought to be piggybacked.

Sure.  My opinion is clear, given what has been presented on the
status of extended label types so far.

> would anyone (other than simon, apparently) agree to make NSEC3 dependent

I strongly disagree that IDN and NSEC3 "needs" this.

IDN could not have used a new label type.  It was a requirement in IDN
that DNS resolvers and servers should not have to be upgraded.

NSEC3 _could_ utilize a new label type, but it is definitely not a
critical dependency, and it brings no advantages that I can see.  A
few disadvantages have already been explained.

Cheers,
Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 24 Oct 2005 15:49:22 +0200

> without having to be quoted:

The point of using a base32 encoding (0-9a-v, a-z0-7 or even
0-9b-df-hj-np-z) was that the alphabet, unlike base64, is not liable
to case folding.  I don't see what benefit a non-alphabetical alphabet
(sic!) would bring.  We have already solved the case-folding problem
by using base32, the only remaining problem is to preserve sort order.

Regards,
Simon

---

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?

---

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: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: 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: 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: Rob Austein <[email-masked]>
Date: Mon, 24 Oct 2005 14:30:11 -0400

I am somewhat leery of getting back into the extended label type
swamp, given how long it took us to figure out the problem last time,
but to be clear on what happened last time:

- Bitlabels were intended to provide a clean way to express addresses
  in the IPv6 reverse tree (it was already too late for IPv4).

- Query usage of bitlabels in the reverse tree would have required
  -every- name server in the resolution path to understand bitlabels,
  because queries are always expressed in terms of the QNAME.  Eg, if
  the name servers for the root zone didn't understand bitlabels,
  using bitlabels in the reverse tree wouldn't work, even though the
  root name servers would always just be delegating to the .arpa
  nameservers -- root server would return Format Error, game over.

- While cleaner, the only place where bitlabels made it possible to do
  something that just couldn't be done with old-fashioned labels was
  when dealing with IPv6 reverse tree entries that needed to be
  delegated in the least significant four bits, which, given the way
  the IPv6 address architecture evolved, is not likely to happen.

- So the joint DNSEXT/NGTRANS WG meeting held to sort out what we
  should do about DNS in IPv6 concluded (somewhat roughly) that the
  pain involved in getting bitlabels to work outweighed the benefits.

It is not immediately obvious to me (either way) which of these
arguments apply to NSEC3.  Last time I checked, the theory was that
one never queries for NSEC or NSEC3 RRs directly, so the issue of
including them as part of the QNAME may not apply here.  There is
still the problem of getting Format Error from implemenetions that
don't understand extended label types, but DNSSEC is a much larger
change to the DNS protocol than support for IPv6 addresses was.

So I dunno.  I would caution all parties to please think this through
and perform the analysis rather than jumping to conclusions (either
way) based on the IPv6 reverse tree example.  We know that it's hard
to get fundamental changes to DNS deployed; we also know that DNSSEC
is a fundamental change that is totally backwards compatable in some
ways and totally backwards incompatible in other ways.  Neither "it
didn't work last time so give up" nor "it didn't work last time but it
damned well should have so let's try again" is likely to help here
(with apologies to anyone who finds this an unkind characterization of
their position on the subject).  We need people thinking hard about
what each entity in the protocol is going to do when it receives these
packets, and we need people running workshops to verify our thinking.

My own guess is that extended label types in this case are not going
to be worth the trouble, because I don't see anything here that can't
be done via more a conservative approach, and thus see no need to live
on the bleeding edge.  But that's just an opinion, and could be wrong.

---

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

---

From: Peter Koch <[email-masked]>
Date: Wed, 26 Oct 2005 16:41:59 +0200

> to prove absence/presence of records with extended label types in its 

No, the DNSSEC-bis set of document simply doesn't cover non-standard labels.
This makes them "unsortable" and thus they are not covered by NSEC RRs.
Presence of RRSets with such labels is no problem at all.

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

Exactly. There were two previous approaches to this anomaly:

1) Declare the owners of NSEC to be outside the namespace - by definition.
   This is straightforward, but has the drawback that the property of the
   name is determined by its ownership of a special RR type.

2) IIRC marka once suggested to use the hash only as an ownername (without
   appending $ORIGIN). Solves the length issue, uses a different namespace
   but more or less changes the paradigm from data based to transaction based.

A new label type makes the owner of an NSEC3 RR be outside the classic
namespace while still being adata based approach.

> Indeed. One would need to define sort-order for 8 bit labels for the 

No, why?

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

It is an anomaly. I do not know whether it will turn out to be an issue.

-Peter

---

From: David Blacka <[email-masked]>
Date: Wed, 26 Oct 2005 11:25:51 -0400

> Presence of RRSets with such labels is no problem at all.

Um, just because RFCs 4033-4035 don't cover non-standard labels  
doesn't make them problem-free wrt DNSSEC.

> namespace while still being adata based approach.

IF this paradox problem is in fact a problem, there is an easier  
solution than #2.

>> Indeed. One would need to define sort-order for 8 bit labels for the

So that any other RR type using the extended label would be coverable  
by DNSSEC.  Or are you suggesting that an extended label type be  
dedicated to NSEC3?

> It is an anomaly. I do not know whether it will turn out to be an  

Me neither.

---

From: Peter Koch <[email-masked]>
Date: Wed, 26 Oct 2005 21:29:35 +0200

> by DNSSEC.  Or are you suggesting that an extended label type be  

"dedicated" in the sense that this label type would primarily satisfy the
needs of NSEC3 -- yes.
"dedicated" in the sense that other RR type MUST NOT be owned by an owner
with such label -- no. Anyone brave enough to do so would have to know
and accept that in this part of the name space there is no authenticated
denial.

-Peter