Subject: Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs -- ...

From: Alfred Hönes <[email-masked]>
Date: Wed, 22 Sep 2010 20:13:14 +0200 (MESZ)

Patrick,
slowly working down now my long backlog of matters to be reviewed
and discussed, I eventually arrived at studying the ITU-T document
(draft ITU-T X.672) referenced in the liaison #903 that you hat
brought to the attention of the apps-discuss list [*] shortly before
IETF in Maastricht.

[*]
 http://www.IETF.ORG/mail-archive/web/apps-discuss/current/msg01613.html

Please feel free to forward the information below (after verification)
via the proper liaison contact.

(1)  major issue

I found one basic misconception of DNS behavior in that document:

Clause 5.2.4 says:

     [...]  sends a query request to a DNS client for NAPTR resource
   records containing the requested ORS information type, ...

This (unfortunately) is a common misconception of DNS behavior, as
also pointed out in the IAB's "Design Choices When Expanding the DNS"
(RFC 5507): a DNS query cannot select by "indirect" keys embedded in
RRs; the DNS client (resolver) can only be commanded to retrieve (and
DNSSEC-verify) an entire RRset.  The responsibility for selecting the
NAPTR RRs containing the application tags in which the ORS client is
interested is entirely with the ORS client itself.  

NOTE:
  Verification of the DNSSEC signature requires the full NAPTR RRset
  at the indicated DNS node -- including all possible application tags.

If the ITU-T / ISO folks want to promote modular use of common/standard
resolver libraries, they should not place unusual additional functional
requirements on these, but instead specify (in clause 5.2.6) that the
ORS has to perform the selection of the NAPTR RRs matching the 
requested ORS information type (via the service field in the returned
NAPTR RDATA).

Fortunately, clause 7 of the ITU-T draft contains a proper description
of the details, but clause 5.2.* should be aligned with the actual 
DNS behavior and clause 7.

(2) minor issues

Another, less technical issue is the definition of DNS zones and
RRsets in the ITU-T draft, which is strongly based on the concept
of a zone *files*.  Doing that in DNSEXT these days would certainly
be regarded as too BIND-centric and hence be very controversial!
In many places in the ITU-T draft, simply replacing "zone file[s]"
by "zone[s]" would be a substantial improvement.

Yet another detail I stumbled over:  In clause 6.1.3, the last two
sentences essentially state that there cannot be empty non-terminal
nodes (in the DNS subtree under consideration).
The text does not make clear that this is an additional requirement
imposed by that specification, not a DNS-internal requirement.
IMO, it would be wise to clarify that.

An ITU-T specific issue seems to be in clause 6.4.2.
I strongly suspect that the error return on finding an unsigned
NAPTR *RRset* (not RR -- a single RR cannot be signed via DNSSEC)
should only be requested if the ORS application had set the security
flag upon its call to the ORS client.  This qualification is missing
in the draft.

Finally, it should be pointed out that RFC 3490 in the meantime has
been superseded by the IDNA-2008 document set, RFCs 5890 thru 5893,
and RFC 5894, giving an overview of that specification and rationale.

I do not understand why the ITU-T draft mandates the use of NSEC3
(invented to prohibit zone enumeration) and at the same time
provides an XML-based service ("CINF") for the enumeration of
delegations (by means of EXTENDED-XER-encoded ASN.1 modules).
(Note that the <noDisclosure/> element is only related to the
ChildInformation CHOICE, not the existence of the child.)
IMO, the (operationally much simpler) use of NSEC would be appropriate
-- at least for those zones that correspond to OID branches that
support the CINF service.

Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 22 Sep 2010 20:20:08 +0200

Thanks!

   paf

On 22 sep 2010, at 20.13, Alfred HÎnes wrote:

>  Alfred HÎnes.