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: "Christian Huitema" <[email-masked]>
Date: Sun, 23 Oct 2005 08:41:45 -0700

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

If we change the alphabet, we should consider a somewhat more
sophisticated solution than 0-9A-V, in order to avoid name collisions
and letter confusion.

Name collision is a classic problem with literal representation of
binary numbers. You can inadvertently obtain a string of letters that
include dictionary words, some of which can be offensive. A simple way
to minimize the problem is to avoid commonly used vowels.

Letter confusion occurs when people have to copy or type in labels. For
example, there is a significant risk of confusing the number 0 and the
letter O, the number 1 and the letter I or the lower case letter l.

The set 0-9A-Z includes 36 code points. The 0-9A-V solution just drops
the last letters in sequence, WXYZ. It may be more productive to remove
the letters A (vowel), E (vowel),  I (vowel, confusion with number 1)
and O (vowel, confusion with number 0).

-- Christian Huitema

---

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

Roy Arends wrote:

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

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.

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

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 
> purpose of dnssec.

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