Subject: draft-ietf-dnsext-unknown-rrs-04.txt

From: Erik Nordmark <[email-masked]>
Date: Thu, 6 Feb 2003 22:21:25 +0100 (CET)

I've done the AD review of this document and I have some questions.

   To avoid such corruption, servers MUST NOT compress domain names
   embedded in the RDATA of types that are class-specific or not well-
   known.  This requirement was stated in RFC1123 without defining the
   term "well-known"; it is hereby specified that only the RR types
   defined in RFC1035 are to be considered "well-known".

The above seems to change the current standard behavior for
SIG, NXT, and perhaps others.

Is this the intent? If so the document should explicitly state this
and also add an "updates RFC 2535" up front. (It also needs an
"updates RFC 1035" up front but that is just an editorial nit).

   For all other RR types, the canonical form is hereby changed such
   that no downcasing of embedded domain names takes place.  The owner
   name is always set to lower case according to the DNS rules for
   character comparisons, regardless of the RR type.

It would be useful to explicitly list the RR types to which this change
applies.

Nits (by themselves not necessitating an updated I-D at this point in time):
The references should be split into normative and non-normative.
A boilerplate IPR section should be added.
(I haven't explicitly checked against the ID-nits page to see if there
are others.)

  Erik

--
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: [email-masked] (Andreas Gustafsson)
Date: Fri, 7 Feb 2003 11:59:13 -0800 (PST)

Erik Nordmark writes:
> SIG, NXT, and perhaps others. Is this the intent?

Yes.  RFC2065 explicitly allowed compression of names in SIG and NXT
records, and this is no longer allowed per the unknown-RRs draft.

As for "perhaps others", I could find one other case where an RR
specification explicitly allows compression: RFC2163 allows
compression in the PX records, which appears to be in direct conflict
with the RFC1035 statement that "Pointers can only be used for
occurances of a domain name where the format is not class specific"
since RFC2163 restricts the PX record to the IN class.

> If so the document should explicitly state this
> and also add an "updates RFC 2535" up front.

I will add this and "updates RFC2163".

> It would be useful to explicitly list the RR types to which this change

That's not really practical since there is more than 65000 of them.
While you could attempt to list the currently allocated post-RFC2915
types, such a list would soon become inaccurate as additional types
are allocated.

> The references should be split into normative and non-normative.

Will do.  It appears there have been quite a number of changes to the
I-D requirements since the initial publication of the draft...

> A boilerplate IPR section should be added.

Can you please point me to a document describing this requirement and
the form of the required boilerplate?
-- 
Andreas Gustafsson, [email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 10 Feb 2003 09:55:10 +0100 (CET)

> records, and this is no longer allowed per the unknown-RRs draft.

But this isn't consistent with draft-ietf-dnsext-dnssec-records-02.txt
which allows compression of SIG and NXT.

Seems like the WG needs to figure out whether they want to allow or prohibit
compression in SIG and NXT. 
And the WG might also want to figure out how
to avoid having the AD be the only one that reads the documents for
consistency :-)/2

> I will add this and "updates RFC2163".

It should also have a paragraph which says exactly what it is updating
e.g. "RFC 2163 allows compression of the xyz field in PX records which
is no longer permitted according to this document ..."

> types, such a list would soon become inaccurate as additional types

I wasn't asking about listing all current and potential future RRs.
I'm asking about a specification of what "hereby changed" actually
means for an implementor. Being able to list the RRs which are subject
to this change seems like a requirement. If you don't have the list
how can we guage the impact of this change?

> I-D requirements since the initial publication of the draft...

Yep. This particular one about separating references is from
the rfc-editor.

> the form of the required boilerplate?

http://www.ietf.org/ID-nits.html 1.2 says:
# IPR notices
From RFC 2026 sec 10.4 (A) and 10.4(B) and possibly 10.4(D)

  Erik

---

From: Rob Austein <[email-masked]>
Date: Mon, 10 Feb 2003 13:18:56 -0500

Presumably we could turn the question around and specify the list of
RR types for which compression of DNS names in the RDATA -is- allowed.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 10 Feb 2003 18:49:49 +0000

> Seems like the WG needs to figure out whether they want to allow or
> prohibit compression in SIG and NXT.

there are two cases, which might be different.  one case is when dnssec
is signalled by a requestor, causing a responder to add SIG and NXT RR's
to the response to prove the validity of the answer.  the other case is
when a normal query (including zone transfers) are used, targetting or
including SIG and NXT RR's.

in the first case, compression could be used, since there is no reason
to believe that the requestor will not understand compression.  dnssec
signalling is a hop by hop affair, based on EDNS0 and new flag bits.  we
are going to change the flag bits or even type codes to ensure that the
2065 or 2535 implementations will not be confused by new things like DS.

in the second case, compression must not be used, since there is every
reason to believe that the requestor will not know the details of the
RDATA layout of these record types, and they need to be able to handle
them as opaque data, including storing zones on disk, caching and reusing
the data in responding to recursive queries, and so on.

the question is, whether compression of the names buys us enough octets
to pay for the complexity of a strategy like "you can use compression if
using this data in an EDNS0-signalled proof, but not in response to a
normal query or transfer".  my own thinking on this is, "not."  that's
because the names aren't always going to have similarities with other
names in the same message (making compression nonbneficial), and also
even a successful compression delta will be dwarfed by the size of the
signature and key data (making compression irrelevant overall).

> And the WG might also want to figure out how to avoid having the AD be
> the only one that reads the documents for consistency :-)/2

one of the things which has characterized the long continuing failure of
dnssec as a standard is a lack of openness.  people mostly won't read
drafts if they believe that they're being written in a star chamber anyway.

that said, i apologize as an individual for humming in the positive on
this draft, without having checked it for consistency.

---

From: [email-masked] (Andreas Gustafsson)
Date: Mon, 10 Feb 2003 11:21:18 -0800 (PST)

> RR types for which compression of DNS names in the RDATA -is- allowed.

Erik Nordmark is not asking about compression (section 4), he is
asking about DNSSEC canonicalization (section 7).  The lists of RRs
pertaining by these two issues (and their complements) are different.
See the discussion on namedroppers on October 25, 2002.
-- 
Andreas Gustafsson, [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Mon, 10 Feb 2003 14:16:26 -0700

>signature and key data (making compression irrelevant overall).

I was going to argue with Paul until I saw the above paragraph. 
Compression in these two records is not worth the cost needed to be 
able to do it.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 11 Feb 2003 13:14:21 -0800 (PST)

> which allows compression of SIG and NXT.

Right.  draft-ietf-dnsext-dnssec-records needs to be fixed.

> how can we guage the impact of this change?

An implementor can construct this list for any given implementation by
finding all RR types the implementation knows about and determining
which ones were defined in an RFC later than RFC2931 (the "2915" in
the quoted text above is a typo and should be "2931" as in the draft).
This will always yield a complete and up-to-date list, unlike any
fixed list that could be embedded in the draft.

Assuming the list of RR type assignments at
<http://www.iana.org/assignments/dns-parameters> is complete, there is
currently exactly one post-RFC2931 RR type, the APL record defined in
RFC3123, but the APL RR does not contain any embedded domain names and
is therefore unaffected by the canonicalization change.  In other
words, the impact of this change on existing implementations is zero.
-- 
Andreas Gustafsson, [email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 11 Feb 2003 22:50:12 +0100 (CET)

> fixed list that could be embedded in the draft.

Future RRs will presumably not have this issue - they will be done right
from the start.

I'm specifically concerned about the statement that unknown-rrs
changes something without being specific about what defined RRs it
is changing.

> words, the impact of this change on existing implementations is zero.

Then it makes sense stating this in unknown-rrs as it *creating a new
rule* that downcasing canocalization of embedded domain names is not performed
for newly created RR types (and perhaps add the list of the defined
RR types that have embedded domain names where downcasing canonicalization 
is performed), instead of as current stating as a *change* to any existing
RRs. That would be much clearer.
(And the stuff in parenthesis could be something which could be deferred to
the new dnssec drafts - being explicit about which RRs have their embedded 
domain names downcased).

  Erik

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 11 Feb 2003 18:48:15 -0800 (PST)

> changes something without being specific about what defined RRs it

And I'm concerned about the use of terms like "defined RRs" and
"existing RRs" since their meaning changes over time.  The draft
already precisely specifies which RRs use which canonicalization rule;
talking about "defined RRs" would be irrelevant and only confuse the
matter, especially for someone reading the RFC ten years from now.

> for newly created RR types

How is this different from what the draft says now?  Could you suggest
a wording which better captures "creating a new rule"?

> (and perhaps add the list of the defined
> is performed),

There is already such a list:

  "the domain names embedded in RRs of type NS, MD, MF, CNAME, SOA, MB,
  MG, MR, PTR, HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT,
  NAPTR, KX, SRV, DNAME, and A6 are converted to lower case according
  to the DNS rules for character comparisons"

> instead of as current stating as a *change* to any existing RRs.

I'm still not sure how you get that impression.  The draft does not
talk about a "changing RRs", it talks about "changing the canonical
form".  Also, it does not talk about "existing RRs", but of "RR types
defined in RFC2931 or earlier" and "other RR types".  Would changing
the text "all other RR types" into "post-RFC2931 RR types" make it
clearer which RRs the new canonical form applies to?
-- 
Andreas Gustafsson, [email-masked]

---

From: Alexis Yushin <[email-masked]>
Date: Wed, 12 Feb 2003 10:47:40 +0100 (CET)

>  to the DNS rules for character comparisons"

Side questions, perhaps I missed the answer, but where does this list
come from?

Alexis

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Feb 2003 11:57:16 +0100 (CET)

> matter, especially for someone reading the RFC ten years from now.

Agreed that "defined RR" and "existing RR" should not be used.
And given that section 7 has the list of RRs that use downcasing
that part is ok (I didn't re-read the section yesterday so I confused
myself - sorry about that.)

The only thing that is odd is the "changed" in the text:
   For all other RR types, the canonical form is hereby changed such
   that no downcasing of embedded domain names takes place.  The owner
   name is always set to lower case according to the DNS rules for
   character comparisons, regardless of the RR type.
where you've identified that there is no change.

To me it makes sense stating instead:

   This document specifies that for all other RR types, the canonical form
   is such that no downcasing of embedded domain names takes place.  The owner
   name is always set to lower case according to the DNS rules for
   character comparisons, regardless of the RR type.

and then add a note saying that

   Note that after RFC 2931 there has been no RR types defined which have
   an embedded domain name. It is expected that future definitions of
   RR types will explicitly state that there is no downcasing of embedded
   domain names as part of DNSSEC canonicalization.

Does that make sense?

In terms on text suggestions, I don't know if I've seen suggested
text that makes it clear that the document changes the compression
rule for SIG and NXT. For the benefits of clarity it makes sense
having that paragraph point at the paragraphs in 2535 that are changed.

  Erik

---

From: Roy Arends <[email-masked]>
Date: Wed, 12 Feb 2003 12:12:50 +0100 (CET)

section 7 of the draft.

Roy

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 14 Feb 2003 10:28:12 -0800 (PST)

>    character comparisons, regardless of the RR type.

OK - I still don't quite see why the word "changed" is so
objectionable, but I have no problem with making this change.

>    an embedded domain name.

This is exactly the kind of statement regarding "defined RRs" I have
already repeatedly objected to adding.  It is true today, but will
become false as soon as additional RR types with embedded domain names
are defined, and would cause nothing but confusion to an implementor
reading it ten years from no.  Such a statement does not belong in an
archival document.

>    It is expected that future definitions of

That is not my expectation.  There is a precedent for explicit
statements regarding the applicability of *compression*, but that is
only because RFC1035 was so ambiguous about where compression was
allowed that it had to be specified in the individual RR type
definitions (and even then some RR definitions interpreted RFC1035
differently from others).  In the case of DNSSEC canonicalization, I
hope the specification will be complete and unambiguous so that we
don't have to resort to that kind of workaround.

> having that paragraph point at the paragraphs in 2535 that are

Can do.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 20 Feb 2003 11:09:15 +0100 (CET)

> reading it ten years from no.  Such a statement does not belong in an

Please suggest alternate text that captures the fact that this section
doesn't change any RR that is currently issued in an RFC and that the intent
is that no future RRs with embedded domain names have this behavior.

> don't have to resort to that kind of workaround.

I don't understand.
I thought you wanted to specify rules to make unmodified servers/caches
be able to handle new RR types. How can you do that if you allow
future RR types to specify different DNSSEC canonicalization rules?

  Erik

---

From: [email-masked] (Andreas Gustafsson)
Date: Thu, 20 Feb 2003 19:41:51 -0800 (PST)

Erik Nordmark writes:
> doesn't change any RR that is currently issued in an RFC

I still think adding text to that effect is a bad idea, regardless of
wording.

If I understand you correctly, the reason you are asking for this text
is is to help assess the impact of the unknown-RRs specification on
implementations that currently exist, or that may exist at the time of
publication of unknown-rrs as an RFC.  That is a reasonable concern,
but it is a meta-concern; it should be part of the current discussion
about the specification, not part of the specification itself.

> future RR types to specify different DNSSEC canonicalization rules?

Of course I don't allow future RR types to specify different DNSSEC
canonicalization rules.  All I said was that I do not expect future
definitions of RR types to *explicitly state* that they use the
unknown-rrs canonicalization algorithm, just like existing definitions
of RR types do not explicitly state that they are using the RFC2535
algorithm.  In the absence of an explicit statement, the unknown-RRs
specification will apply, just like RFC2535 applies today.
-- 
Andreas Gustafsson, [email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 21 Feb 2003 10:24:55 +0100 (CET)

> about the specification, not part of the specification itself.

You at least understand my concern.

I don't understand why you don't agree with it.
The IETF produces documentation that try to be clear enough so that folks
can (with reasonable probability) produce interoperable implementations
from the specification. 
If a specification changes some other specification it makes a lot of
sense to make the change clear enough so that an implementor can
understand the change.

But when I asked you about the change you reviewed the specifications
and said that there is no change to existing RRs.
I then suggested that the reason you said "change" was because you wanted
to change the practise used for defining future RRs.
You balked at that proposal - but perhaps it was just a wording detail ...

> specification will apply, just like RFC2535 applies today.

So the 3rd paragraph in section 7 changes the practise for future definitions
of RRs? They can not have downcasing of embedded domain names.

Then it makes sense to say that and not say "For all other RR types ...".
And it is useful to implementors to point out that no RRs that have
been defined after RFC 2931 and this RFC contain embedded domain names".
(There aren't any RR definitions in the IETF last call, IESG, RFC-editor
pipeline right now and if any appear I'll make sure they get this right.)

  Erik

---

From: [email-masked] (Andreas Gustafsson)
Date: Fri, 21 Feb 2003 14:35:33 -0800 (PST)

> sense to make the change clear enough so that an implementor can

Of course, but I think the changes you suggested would make the
specification less clear, not clearer.

> You balked at that proposal - but perhaps it was just a wording detail ...

The intent of the draft is that the new canonicalization algorithm
will apply to all future RR types.  I don't think there is any
disagreement about that.  The disagreement seems to be about two other
issues:

1. The use of temporal terms such as "current", "future", or
"existing" in the text of the specification.  That would only cause
confusion since an RR type which we today consider a "future" type is
likely to be an "existing" type when an implementor reads the RFC some
time in the future.  An explicit listing of the RRs that use the old
algorithm and a statement that all others use the new algorithm is
unambiguous, whereas a reference to "future types" is not.

2. When you say the draft wants to "change the practice used for
defining future RRs", you seem to be assuming that the DNSSEC
canonicalization algorithm to be used for any given RR type is part of
the RR type definition itself.  That has not traditionally been the
case - no existing RR type definition contains any mention of
downcasing or other aspects DNSSEC canonicalization, and there is no
reason for future ones to contain such specific mention, either. The
erefore, section 7 does not change the "practice of defining new RRs";
it only changes a part of the DNSSEC specification.

Furthermore, saying that the draft "changes the practice used for
defining future RRs" could be incorrectly interpreted as meaning the
new canonicalization algorithm only begins to apply to a new RR type
once it gets defined, when in fact it will apply even *before* it is
defined, when it is still only an unallocated RR type number being
treated transparently by implementations.  Keep in mind that the
reason why this change is being made in the first place is to ensure
that new RR types are canonicalized identically by all implementations
even if they are treated as known types by some implementations and as
unknown types by others.

> pipeline right now and if any appear I'll make sure they get this right.)

Did you mean "after RFC2931 but before this RFC"?

If you can guarantee that no new RR types with embedded domain names
are published as RFCs before the publication of unknown-RRs as an RFC,
then I have no problem with including a statement to that effect.

Regarding the possibility of publishing new RR types with embedded
domain names before unknown-RRs and making sure they "get it right",
that's much more problematic.  It would mean that these new RR type
definitions would not only have to explicitly mention DNSSEC
canonicalization (unlike previous RR type definitions), but they would
also have to contain a copy of the text from section 7 defining the
new canonicalization algorithm, and they would have to update RFC2535.
Also, I'm not sure what the text you want added to the unknown-RRs RFC
would say in that case - clearly it could not say "no RR types defined
at the time of the publication of this RFC use the new
canonicalization rules" nor "no RR types defined between RFC2931 and
this RFC have embedded domain names", since neither statement would be
true.
-- 
Andreas Gustafsson, [email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 24 Feb 2003 16:50:39 +0100 (CET)

> Did you mean "after RFC2931 but before this RFC"?

Yes.

Upleveling. 
Since you seem to understand my concern but disagree with every textual
proposal I suggest to try to make things more clear, why
don't you suggest some clarifications to the text that make things
more clear?

  Erik

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 25 Feb 2003 17:37:00 -0800 (PST)

> don't you suggest some clarifications to the text that make things

Since this perceived lack of clarity seems to be related to the use of
the time of publication of RFC2931 as a flag day, would you find it
clearer if the time of publication of unknown-RRs itself as an RFC
were used instead?

Here is an updated and expanded section 7 with this change as well as
some added rationale and other clarifications.  Using this text will
of course require that no new RR types with embedded domain names are
defined before this is published as an RFC.  Also, the RFC editor
needs to replace "TBD" with the actual RFC number of the unknown-rrs
RFC itself.

   7. DNSSEC Canonical Form and Ordering

   DNSSEC defines a canonical form and ordering for RRs [RFC2535, section
   8.1].  In that canonical form, domain names embedded in the RDATA are
   converted to lower case.

   The downcasing is necessary to ensure the correctness of DNSSEC
   signatures when case distinctions in domain names are lost due to
   compression, but since it requires knowledge of the presence and
   position of embedded domain names, it cannot be applied to unknown
   types.

   To ensure continued consistency of the canonical form of RR types
   where compression is allowed, and for continued interoperability
   with existing implementations that already implement the RFC2535
   canonical form and apply it to their known RR types, the canonical
   form remains unchanged for all RR types whose whose initial
   publication as an RFC was prior to the initial publication of this
   specification as an RFC (RFC TBD).

   As a courtesy to implementors, it is hereby noted that the complete
   set of such previously published RR types that contain embedded
   domain names, and whose DNSSEC canonical form therefore involves
   downcasing according to the DNS rules for character comparisons,
   consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
   HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
   SRV, DNAME, and A6.

   This document specifies that for all other RR types (whether
   treated as unknown types or treated as known types according to an
   RR type definition RFC more recent than than RFC TBD), the
   canonical form is such that no downcasing of embedded domain names
   takes place, and otherwise identical to the canonical form
   specified in RFC2535 section 8.1.

   Note that the owner name is always set to lower case according to the
   DNS rules for character comparisons, regardless of the RR type.

   The DNSSEC canonical RR ordering is as specified in RFC2535 section
   8.3, where the octet sequence is the canonical form as revised by this
   specification.

Would this text be acceptable?
-- 
Andreas Gustafsson, [email-masked]