base32 alphabet rant - rhaaaaa rfc3548
Roy Arends
"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 namedroppe...@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>
Simon Josefsson
> 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
Paul Vixie
# > "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.
Ben Laurie
> # > 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.
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
Simon Josefsson
> # > 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.
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
Paul Vixie
# 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.
Simon Josefsson
> 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.
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.
> 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.
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
Paul Vixie
# 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.
Simon Josefsson
> # 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.
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...
> # ... 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.
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
Simon Josefsson
>>> 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.
>
> 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,
Paul Vixie
# ?
#
# 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?
Simon Josefsson
> On Sat, 22 Oct 2005, Simon Josefsson wrote:
>
>> Roy Arends <r...@dnss.ec> writes:
>>
>>>>> 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.
>>>
>>> Is the pending-nits combined with a second alphabet for base32
>>> substantional enough to justify 3548-bis ?
>>
>> We only find out if we try.
>
> 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
Christian Huitema
> 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
Simon Josefsson
>> 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).
Changing the alphabet would be fine if rfc3548bis aimed for the
standards track. However, currently, rfc3548 is merely informative,
and the aim was to try to document existing practices. We know 0-9a-z
is used, it is from rfc 2938, and a-z2-7 was used in the SASL WG
document.
I believe base-n encoding are important enough to be on the standards
track. I will aim for that in the revised document, and see if people
approve.
I'll propose to make the "standard" base32 alphabet be the
0-9b-df-hj-np-z alphabet. It preserve sort order (which was the
requirement here) and it avoid some easily visually confusing letters
(which was the requirement in rfc3548). It sometime also avoid
offensive words, which is a nice feature. However, if that was a
requirement, we would need a more complicated set of rules (I believe
there are offensive words that don't contain a, e, i, or o).
Thanks,
Simon
Roy Arends
> Roy Arends <r...@dnss.ec> 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/>.
That would be a good thing.
>> 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.
That would be a good thing too.
>> 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.
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
Roy Arends
>> 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).
The I!=1 and O!=0 confusion I can somewhat understand, eventhough this
doesn't really apply to NSEC3 imho.
Trying to create an alphabet that avoids base32 encoded data parts
colliding with some dictionary word in some language is a nice social
idea, but just doesn't scale, hence rediculous to require. (You may still
upset those Tashlhiyt' Berber speaking folk if you'd avoid vowels). It
might be a classic problem, but not on this layer.
Olaf M. Kolkman
--Apple-Mail-12--638442272
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
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:
> 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.
>
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/
--Apple-Mail-12--638442272
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: This message is locally signed.
iD8DBQFDXJHAtN/ca3YJIocRAgARAJ9KW1bxTb3elESjB8WHSJewjpL9ZwCePSbe
7UEJxlpKUhAiInvgOHjYo94=
=fGMl
-----END PGP SIGNATURE-----
--Apple-Mail-12--638442272--
Peter Koch
> 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.
this could also elegantly solve the "paradox problem", where the NSEC3 chain
denies its owners' existance.
-Peter
Roy Arends
> 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:
>
>> 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.
>>
>
> 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
Roy Arends
> Paul Vixie wrote:
>
>> 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.
>
> this could also elegantly solve the "paradox problem", where the NSEC3 chain
> denies its owners' existance.
Does it matter wrt the paradox problem if a label exists at labeltype 00
or labeltype 0100002 ?
Ben Laurie
> 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:
>>
>>> 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.
>>>
>>
>> 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.
You have 1.5 hours to submit -04 :-)
"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
--
Ben Laurie
> Paul Vixie wrote:
>
>> 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.
>
> 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.
Peter Koch
> 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
bert hubert
> > 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.
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
Simon Josefsson
> # 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?
Well, we are still discussing the matter.
> 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!)
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.
> # 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 disagree.
> # 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.
Sure. My opinion is clear, given what has been presented on the
status of extended label types so far.
> 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?
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
Simon Josefsson
> Olaf Kolkman writes:
>
> [...]
>> 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.
>
> 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 ...
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,
Ben Laurie
> Ben Laurie wrote:
>
>> It could? How? Are you suggesting that different label types are somehow
>> in different spaces?
>
> Roy Arends wrote:
>
>> 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.
>
> 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.
Don't we have enough careful consideration already?
"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
--
Roy Arends
> 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.
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 ?
> 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".
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.
>> 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.
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.
> However, the new label type might add some complexity which would need
> very careful consideration.
I don't think the 'paradox problem' is a real issue.
Roy
Paul Vixie
# 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.
David Blacka
On Oct 24, 2005, at 12:33 PM, Paul Vixie wrote:
> # 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.
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.
> # 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.
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 <dav...@verisignlabs.com>
Sr. Engineer VeriSign Applied Research
Alex Bligh
--On 24 October 2005 16:33 +0000 Paul Vixie <pa...@vix.com> wrote:
> 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
Mike StJohns
># 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.
>
>
># 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.
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*
Paul Vixie
#
# 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.)
Paul Vixie
#
# 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 :-).
Paul Vixie
# >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.
David Blacka
On Oct 24, 2005, at 1:20 PM, Paul Vixie wrote:
> # > 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.
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
> query :-).
NSEC3 doesn't introduce extra queries AFAICT.
--
David Blacka <dav...@verisignlabs.com>
Sr. Engineer VeriSign Applied Research
Paul Vixie
# 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"?
David Blacka
On Oct 24, 2005, at 1:14 PM, Paul Vixie wrote:
> # 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.)
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.
--
David Blacka <dav...@verisignlabs.com>
Sr. Engineer VeriSign Applied Research
Rob Austein
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.
Olaf M. Kolkman
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
On Oct 24, 2005, at 19:20 , Paul Vixie wrote:
> 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,
>
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/
--Apple-Mail-26--594697273
content-type: application/pgp-signature; x-mac-type=70674453;
name=PGP.sig
content-description: This is a digitally signed message part
content-disposition: inline; filename=PGP.sig
content-transfer-encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: This message is locally signed.
iD8DBQFDXTystN/ca3YJIocRAvQdAKCdf8hBKhAIJQ4nDMfFQsts7ZategCg4Gau
ITVyTL8dOsgzdb/TjoCLPXo=
=y3Qg
-----END PGP SIGNATURE-----
--Apple-Mail-26--594697273--
Chris Thompson
[...]
> 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.
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: ce...@cam.ac.uk
Simon Josefsson
> On Sat, 22 Oct 2005, Simon Josefsson wrote:
>
>> Roy Arends <r...@dnss.ec> 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/>.
>
> That would be a good thing.
I have submitted the draft, and it has been published (see below).
Are there any base-* considerations that you need for NSEC3 that isn't
in the document? Any other suggestions? If not, I'll ask the RFC
Editor to publish it.
Thanks,
Simon
> Title : The Base16, Base32, and Base64 Data Encodings
>
> This document describes the commonly used base 64, base 32, and base
> 16 encoding schemes. It also discusses the use of line-feeds in
> encoded data, use of padding in encoded data, use of non-alphabet
> characters in encoded data, and use of different encoding alphabets.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-josefsson-rfc3548bis-00.txt
Roy Arends
> I have submitted the draft, and it has been published (see below).
>
> Are there any base-* considerations that you need for NSEC3 that isn't
> in the document? Any other suggestions? If not, I'll ask the RFC
> Editor to publish it.
Not that I can think of, though I suggest to rewrite the ambiguous "zero
bits are added" into "bits with value zero are added" (which appears twice
in the document).
Thanks,
Roy
Simon Josefsson
> On Tue, 15 Nov 2005, Simon Josefsson wrote:
>
>> I have submitted the draft, and it has been published (see below).
>>
>> Are there any base-* considerations that you need for NSEC3 that isn't
>> in the document? Any other suggestions? If not, I'll ask the RFC
>> Editor to publish it.
>
> Not that I can think of, though I suggest to rewrite the ambiguous
> "zero bits are added" into "bits with value zero are added" (which
> appears twice in the document).
Fixed in my local copy, thanks.
Btw, the live version can be tracked through:
http://josefsson.org/base-encoding/
Regards,
Simon
Ben Laurie
> On Tue, 15 Nov 2005, Simon Josefsson wrote:
>
>> I have submitted the draft, and it has been published (see below).
>>
>> Are there any base-* considerations that you need for NSEC3 that isn't
>> in the document? Any other suggestions? If not, I'll ask the RFC
>> Editor to publish it.
>
> Not that I can think of, though I suggest to rewrite the ambiguous "zero
> bits are added" into "bits with value zero are added" (which appears
> twice in the document).
Hmm. Can I be lazy and ask if it supports unpadded modes? If not, can it?
** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ **
"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
--
Ben Laurie
>>
>>> Roy Arends <r...@dnss.ec> 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/>.
>> That would be a good thing.
>
>
> Are there any base-* considerations that you need for NSEC3 that isn't
> in the document? Any other suggestions? If not, I'll ask the RFC
> Editor to publish it.
Yes, it should be case-blind. I was going to say that in the NSEC3 I-D,
but far better if its in RFC3548bis.
Simon Josefsson
> Roy Arends wrote:
>> On Tue, 15 Nov 2005, Simon Josefsson wrote:
>>
>>> I have submitted the draft, and it has been published (see below).
>>>
>>> Are there any base-* considerations that you need for NSEC3 that isn't
>>> in the document? Any other suggestions? If not, I'll ask the RFC
>>> Editor to publish it.
>> Not that I can think of, though I suggest to rewrite the ambiguous
>> "zero bits are added" into "bits with value zero are added" (which
>> appears twice in the document).
>
> Hmm. Can I be lazy and ask if it supports unpadded modes? If not, can it?
They aren't discussed. I need them in the SASL GS2-* mechanism as
well (seems I ended up as co-author on that..), so adding a section on
that seem appropriate. I have added it to the todo list.
Thanks,
Simon