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

[Patrik Fältström <[e-mail]>]

Thanks!

   paf

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

> 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: [phone], Fax: -18         |
> | D-71254  Ditzingen     |  E-Mail:  [e-mail]                     |
> +------------------------+--------------------------------------------+
> 
>