Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs -- ...
Alfred Hönes <ah@TR-Sys.de> Wed, 22 September 2010 18:17 UTC
Return-Path: <A.Hoenes@TR-Sys.de>
X-Original-To: apps-discuss@core3.amsl.com
Delivered-To: apps-discuss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64AB73A6B45 for <apps-discuss@core3.amsl.com>; Wed, 22 Sep 2010 11:17:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.828
X-Spam-Level:
X-Spam-Status: No, score=-97.828 tagged_above=-999 required=5 tests=[AWL=0.921, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmwbGotKEdwP for <apps-discuss@core3.amsl.com>; Wed, 22 Sep 2010 11:17:05 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id CF7233A6ABC for <apps-discuss@ietf.org>; Wed, 22 Sep 2010 11:17:01 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA206449196; Wed, 22 Sep 2010 20:13:16 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id UAA26387; Wed, 22 Sep 2010 20:13:14 +0200 (MESZ)
From: Alfred Hönes <ah@TR-Sys.de>
Message-Id: <201009221813.UAA26387@TR-Sys.de>
To: patrik@frobbit.se
Date: Wed, 22 Sep 2010 20:13:14 +0200
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset="hp-roman8"
Content-Transfer-Encoding: quoted-printable
Cc: dnsext-chairs@tools.ietf.org, dnsop-chairs@tools.ietf.org, apps-discuss@ietf.org
Subject: Re: [apps-discuss] Review of liaison from ITU-T regarding OIDs -- ...
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Sep 2010 18:17:15 -0000
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: ah@TR-Sys.de | +------------------------+--------------------------------------------+
- Re: [apps-discuss] Review of liaison from ITU-T r… Alfred Hönes
- Re: [apps-discuss] Review of liaison from ITU-T r… Patrik Fältström