Subject: Re: base32 alphabet rant - rhaaaaa rfc3548

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

Roy Arends <[email-masked]> writes:

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

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

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.

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

I agree.

Regards,
Simon

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