From dromasca@avaya.com Sun Jan 1 03:22:49 2012 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1483F21F847C; Sun, 1 Jan 2012 03:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.258 X-Spam-Level: X-Spam-Status: No, score=-103.258 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adz46mvchast; Sun, 1 Jan 2012 03:22:47 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 534DA21F8482; Sun, 1 Jan 2012 03:22:42 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAEBBAE/GmAcF/2dsb2JhbABCggWDCpsrixeBBIEFgXIBAQEBAxIRDQQ+EwYBCA0IBQIGBgwLAQICAwEfJQcBBgQBBAESCBqhCIlvkHaBL4lKM2MEmnGFAIdG X-IronPort-AV: E=Sophos;i="4.71,440,1320642000"; d="scan'208";a="284270913" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Jan 2012 06:22:39 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Jan 2012 06:18:50 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Sun, 1 Jan 2012 12:22:34 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the January 5, 2012 IESG Teleconference Thread-Index: AczGgq+j0FT9W6rdTy+pz+9lo3ISEQB9JbcQ From: "Romascanu, Dan (Dan)" To: , , "YANG Doctors" , , "IETF DNS Directorate" Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for the January 5, 2012 IESG Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Jan 2012 11:22:49 -0000 UGxlYXNlIGZpbmQgYmVsb3cgdGhlIHByZWxpbWluYXJ5IGFnZW5kYSBvZiB0aGUgMS81IElFU0cg dGVsZWNoYXQuIFBsZWFzZSBzZW5kIHlvdXIgcXVlc3Rpb25zLCBjb21tZW50cyBhbmQgY29uY2Vy bnMgYWJvdXQgdGhlIGRvY3VtZW50IGFuZCBXRyBjaGFydGVycyBicm91Z2h0IHVwIGZvciB0aGUg YXBwcm92YWwgb2YgdGhlICBJRVNHIGJlZm9yZSAxLzQgQ09CLiANCg0KVGhhbmtzIGFuZCBSZWdh cmRzLA0KDQpEYW4NCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpZXNn LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppZXNnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBJRVNHIFNlY3JldGFyeQ0KDQoNCjIuIFByb3RvY29sIEFjdGlvbnMNCjIuMSBXRyBTdWJt aXNzaW9ucw0KMi4xLjEgTmV3IEl0ZW1zDQoNCiAgbyBkcmFmdC1pZXRmLXNpZXZlLWluY2x1ZGUt MTMNCiAgICBTaWV2ZSBFbWFpbCBGaWx0ZXJpbmc6IEluY2x1ZGUgRXh0ZW5zaW9uIChQcm9wb3Nl ZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBCYXJyeSBMZWliYSAoYmFycnlsZWliYUBjb21wdXRlci5v cmcpIGlzIHRoZSBkb2N1bWVudA0KICAgIHNoZXBoZXJkLg0KICAgIFRva2VuOiBQZXRlIFJlc25p Y2sNCg0KICBvIGRyYWZ0LWlldGYtc29mdHdpcmUtZ2F0ZXdheS1pbml0LWRzLWxpdGUtMDYNCiAg ICBHYXRld2F5IEluaXRpYXRlZCBEdWFsLVN0YWNrIExpdGUgRGVwbG95bWVudCAoUHJvcG9zZWQg U3RhbmRhcmQpDQogICAgTm90ZTogWW9uZyBDdWkgKGN1aXlvbmdAdHNpbmdodWEuZWR1LmNuKSBp cyB0aGUgZG9jdW1lbnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFJhbHBoIERyb21zDQoNCiAgbyBk cmFmdC1pZXRmLTZsb3dwYW4tbmQtMTgNCiAgICBOZWlnaGJvciBEaXNjb3ZlcnkgT3B0aW1pemF0 aW9uIGZvciBMb3cgUG93ZXIgYW5kIExvc3N5IE5ldHdvcmtzDQogICAgKDZMb1dQQU4pIChQcm9w b3NlZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBDYXJzdGVuIEJvcm1hbm4gKGNhYm9AdHppLm9yZykg aXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBSYWxwaCBEcm9tcw0KDQogIG8g ZHJhZnQtaWV0Zi02bWFuLWV4dGhkci0wNQ0KICAgIEFuIHVuaWZvcm0gZm9ybWF0IGZvciBJUHY2 IGV4dGVuc2lvbiBoZWFkZXJzIChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBCcmlhbiBI YWJlcm1hbiAoYnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0KSBpcyB0aGUgZG9jdW1lbnQNCiAgICBz aGVwaGVyZC4NCiAgICBUb2tlbjogSmFyaSBBcmtrbw0KDQogIG8gZHJhZnQtaWV0Zi1zdG9ybS1y ZGRwLXJlZ2lzdHJpZXMtMDENCiAgICBJQU5BIFJlZ2lzdHJpZXMgZm9yIHRoZSBSRERQIChSZW1v dGUgRGlyZWN0IERhdGEgUGxhY2VtZW50KQ0KICAgIFByb3RvY29scyAoUHJvcG9zZWQgU3RhbmRh cmQpDQogICAgTm90ZTogRGF2aWQgQmxhY2sgKGRhdmlkLmJsYWNrQGVtYy5jb20pIGlzIHRoZSBk b2N1bWVudCBzaGVwaGVyZC4NCiAgICBUb2tlbjogRGF2aWQgSGFycmluZ3Rvbg0KDQoyLjEuMiBS ZXR1cm5pbmcgSXRlbXMNCg0KICBvIGRyYWZ0LWlldGYtZGhjLXZwbi1vcHRpb24tMTQNCiAgICBW aXJ0dWFsIFN1Ym5ldCBTZWxlY3Rpb24gT3B0aW9ucyBmb3IgREhDUHY0IGFuZCBESENQdjYgKFBy b3Bvc2VkDQogICAgU3RhbmRhcmQpDQogICAgTm90ZTogSm9obiBKYXNvbiBCcnpvem93c2tpIChq b2huX2Jyem96b3dza2lAY2FibGUuY29tY2FzdC5jb20pIGlzDQogICAgdGhlIGRvY3VtZW50IHNo ZXBoZXJkLg0KICAgIFRva2VuOiBSYWxwaCBEcm9tcw0KDQogIG8gZHJhZnQtaWV0Zi1pcHBtLW1l dHJpY3Rlc3QtMDUNCiAgICBJUFBNIHN0YW5kYXJkIGFkdmFuY2VtZW50IHRlc3RpbmcgKEJDUCkN CiAgICBOb3RlOiBIZW5rIFVpanRlcndhYWwgKGhlbmtAdWlqdGVyd2FhbC5ubCkgaXMgdGhlIGRv Y3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBXZXNsZXkgRWRkeQ0KDQoyLjIgSW5kaXZpZHVh bCBTdWJtaXNzaW9ucw0KMi4yLjEgTmV3IEl0ZW1zDQoNCiAgbyBkcmFmdC1kYWJvby13ZWJkYXYt c3luYy0wNg0KICAgIENvbGxlY3Rpb24gU3luY2hyb25pemF0aW9uIGZvciBXZWJEQVYgKFByb3Bv c2VkIFN0YW5kYXJkKQ0KICAgIFRva2VuOiBQZXRlciBTYWludC1BbmRyZQ0KDQogIG8gZHJhZnQt Z3JlZ29yaW8tdXJpdGVtcGxhdGUtMDcNCiAgICBVUkkgVGVtcGxhdGUgKFByb3Bvc2VkIFN0YW5k YXJkKQ0KICAgIE5vdGU6IE11cnJheSBLdWNoZXJhd3kgPG1za0BjbG91ZG1hcmsuY29tPiBpcyB0 aGUgRG9jdW1lbnQNCiAgICBTaGVwaGVyZC4NCiAgICBUb2tlbjogUGV0ZXIgU2FpbnQtQW5kcmUN Cg0KMi4yLjIgUmV0dXJuaW5nIEl0ZW1zDQoNCiAgTk9ORQ0KDQozLiBEb2N1bWVudCBBY3Rpb25z DQozLjEgV0cgU3VibWlzc2lvbnMNCjMuMS4xIE5ldyBJdGVtcw0KDQogIG8gZHJhZnQtaWV0Zi1z aXBjbGYtcHJvYmxlbS1zdGF0ZW1lbnQtMDkNCiAgICBUaGUgQ29tbW9uIExvZyBGb3JtYXQgKENM RikgZm9yIHRoZSBTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wNCiAgICAoU0lQKTogRnJhbWV3 b3JrIGFuZCBEYXRhIE1vZGVsIChJbmZvcm1hdGlvbmFsKQ0KICAgIE5vdGU6IFBldGVyIE11c2dy YXZlIChtdXNncmF2ZXBqQGdtYWlsLmNvbSkgaXMgdGhlIGRvY3VtZW50DQogICAgc2hlcGhlcmQu DQogICAgVG9rZW46IFJvYmVydCBTcGFya3MNCg0KMy4xLjIgUmV0dXJuaW5nIEl0ZW1zDQoNCiAg Tk9ORQ0KDQozLjEuMyBGb3IgQWN0aW9uDQoNCiAgbyBkcmFmdC1pZXRmLXJ0Z3dnLWxmYS1hcHBs aWNhYmlsaXR5LTA0DQogICAgTEZBIGFwcGxpY2FiaWxpdHkgaW4gU1AgbmV0d29ya3MgKEluZm9y bWF0aW9uYWwpDQogICAgTm90ZTogQWx2YXJvIFJldGFuYSAoYWx2YXJvLnJldGFuYUBocC5jb20p IGlzIHRoZSBkb2N1bWVudCBzaGVwaGVyZC4NCiAgICBUb2tlbjogU3Rld2FydCBCcnlhbnQNCg0K My4yIEluZGl2aWR1YWwgU3VibWlzc2lvbnMgVmlhIEFEDQozLjIuMSBOZXcgSXRlbXMNCg0KICBv IGRyYWZ0LWFya2tvLWlwdjYtb25seS1leHBlcmllbmNlLTA0DQogICAgRXhwZXJpZW5jZXMgZnJv bSBhbiBJUHY2LU9ubHkgTmV0d29yayAoSW5mb3JtYXRpb25hbCkNCiAgICBUb2tlbjogUm9uIEJv bmljYQ0KDQogIG8gZHJhZnQtb2h5ZS1jYW5vbmljYWwtbGluay1yZWxhdGlvbi0wNA0KICAgIFRo ZSBDYW5vbmljYWwgTGluayBSZWxhdGlvbiAoSW5mb3JtYXRpb25hbCkNCiAgICBUb2tlbjogUGV0 ZXIgU2FpbnQtQW5kcmUNCg0KICBvIGRyYWZ0LWt1Y2hlcmF3eS1ka2ltLWF0cHMtMTMNCiAgICBE S0lNIEF1dGhvcml6ZWQgVGhpcmQtUGFydHkgU2lnbmVycyAoRXhwZXJpbWVudGFsKQ0KICAgIE5v dGU6IEJhcnJ5IExlaWJhIChiYXJyeWxlaWJhQGNvbXB1dGVyLm9yZykgaXMgdGhlIGRvY3VtZW50 DQogICAgc2hlcGhlcmQuDQogICAgVG9rZW46IFNlYW4gVHVybmVyDQoNCiAgbyBkcmFmdC1hbXVu ZHNlbi1pdGVtLWFuZC1jb2xsZWN0aW9uLWxpbmstcmVsYXRpb25zLTA0DQogICAgVGhlIEl0ZW0g YW5kIENvbGxlY3Rpb24gTGluayBSZWxhdGlvbnMgKEluZm9ybWF0aW9uYWwpDQogICAgVG9rZW46 IFBldGVyIFNhaW50LUFuZHJlDQoNCiAgbyBkcmFmdC15ZXZzdGlmZXlldi1kaXNjbG9zdXJlLXJl bGF0aW9uLTAwDQogICAgVGhlICdkaXNjbG9zdXJlJyBMaW5rIFJlbGF0aW9uIFR5cGUgKEluZm9y bWF0aW9uYWwpDQogICAgTm90ZTogVGhlIElFVEYgTGFzdCBDYWxsIGVuZHMgb24gSmFudWFyeSA2 Lg0KICAgIFRva2VuOiBQZXRlciBTYWludC1BbmRyZQ0KDQozLjIuMiBSZXR1cm5pbmcgSXRlbXMN Cg0KICBOT05FDQoNCjMuMyBJUlRGIGFuZCBJbmRlcGVuZGVudCBTdWJtaXNzaW9uIFN0cmVhbSBE b2N1bWVudHMNCjMuMy4xIE5ldyBJdGVtcw0KDQogIE5PTkUNCg0KMy4zLjIgUmV0dXJuaW5nIEl0 ZW1zDQoNCiAgTk9ORQ0KDQo0LiBXb3JraW5nIEdyb3VwIEFjdGlvbnMNCjQuMSBXRyBDcmVhdGlv bg0KNC4xLjEgUHJvcG9zZWQgZm9yIElFVEYgUmV2aWV3DQoNCiAgTk9ORQ0KDQo0LjEuMiBQcm9w b3NlZCBmb3IgQXBwcm92YWwNCg0KICBvIFNQRiBVcGRhdGUgKHNwZmJpcykNCiAgICBUb2tlbjog UGV0ZQ0KDQo0LjIgV0cgUmVjaGFydGVyaW5nDQo0LjIuMSBVbmRlciBFdmFsdWF0aW9uIGZvciBJ RVRGIFJldmlldw0KDQogIG8gRGlzdHJpYnV0ZWQgTW9iaWxpdHkgTWFuYWdlbWVudCAoZG1tKQ0K ICAgIFRva2VuOiBKYXJpDQoNCiAgbyBMb2NhdG9yL0lEIFNlcGFyYXRpb24gUHJvdG9jb2wgKGxp c3ApDQogICAgVG9rZW46IEphcmkNCg0KICBvIFJvdXRpbmcgQXJlYSBXb3JraW5nIEdyb3VwIChy dGd3ZykNCiAgICBUb2tlbjogU3Rld2FydA0KDQogIG8gRGlhbWV0ZXIgTWFpbnRlbmFuY2UgYW5k IEV4dGVuc2lvbnMgKGRpbWUpDQogICAgVG9rZW46IERhbg0KDQoNCg== From peter@denic.de Wed Jan 4 10:17:11 2012 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA99321F85EA for ; Wed, 4 Jan 2012 10:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzV3Bjh8pN6a for ; Wed, 4 Jan 2012 10:17:11 -0800 (PST) Received: from office.denic.de (office.denic.de [IPv6:2a02:568:122:16:1::4]) by ietfa.amsl.com (Postfix) with ESMTP id EA80F21F8551 for ; Wed, 4 Jan 2012 10:17:10 -0800 (PST) Received: from x27.adm.denic.de ([10.122.64.128]) by office.denic.de with esmtp id 1RiVOf-0002OY-HE; Wed, 04 Jan 2012 19:17:09 +0100 Received: from localhost by x27.adm.denic.de with local id 1RiVOf-0007e8-CJ; Wed, 04 Jan 2012 19:17:09 +0100 Date: Wed, 4 Jan 2012 19:17:09 +0100 From: Peter Koch To: Ondrej Sury Message-ID: <20120104181709.GP13424@x27.adm.denic.de> Mail-Followup-To: Ondrej Sury , dns-dir@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Sender: Peter Koch Cc: dns-dir@ietf.org Subject: [dns-dir] some comments on draft-os-ietf-sshfp-ecdsa-sha2-04.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 18:17:11 -0000 Hi Ondrej, i came across another review of and would like to add some remarks. I've copied the DNS Directorate for information. Not sure what the status of the draft is - the datatracker confuses me by claiming 'wg document', but i do not see which WG? Generally the draft looks like a good idea! To start with some formalities, the header and abstract claim the draft updates RFC 4255. I would suggest it does not. It updates two IANA registries defined and seeded by RFC 4255, but it does not (to my reading) change any content of RFC 4255. If it were to update 4255, it should probably adjust the registry policies from "IETF consensus" as per RFC 2434 to "IETF Review" as per RFC 5226, but that's probably for another venue to discuss. Second, the document aims at Standards Track and I do not see why. An IETF/IESG reviewed RFC would be sufficient. Not saying it should be less than ST, but what's the purpose here? Later serving as normative reference? In section 3.2 the use of an ECDSA fingerprint is defined. I could not find the description of the Fingerprint in RFC 5656. Furtheron it reads ECDSA public key fingerprints MUST use the SHA-256 algorithm for the fingerprint as using the SHA-1 algorithm would weaken the security of the key. First, could the claim 'would weaken the security' be substantiated (maybe by reference) a bit? Second, what is the consequence, i.e. who is supposed to act on a violation? Is it the DNS implementation (hard to achieve with 'transparent' RR types), the DNS operator or the consuming entity? I would suggest to reverse the logic here and only demand that a consuming party MUST ignore SHA-1 FPs for ECDSA. In 4.1, the SHA-256 fingerprint is introduced. The consuming entity is advised "Secure Shell implementations which support SHA-256 fingerprints MUST prefer a SHA- 256 fingerprint over SHA-1 if both are available for a server. If the SHA-256 fingerprint is tested and does not match the supplied key, then the key MUST be rejected rather than testing the alternative SHA-1 fingerprint." This assumes that both FPs are for the same key? Couldn't it happen that the server offers an RSA and an ECDSA key, using SHA-1 for the former and ECDSA for the latter? Nit: Add some text after the headline "5. Examples", e.g. The following examples provide reference for both the newly defined ECDSA algorithm number and the use of the SHA-256 fingerprint combined with both the new and the existing algorithm numbers. The examples refer to "OpenSSH format" without any reference. The references to the DNSSEC RFCs are probably informative only. Best regards, Peter From ondrej.sury@nic.cz Wed Jan 4 10:36:42 2012 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D2821F87A1 for ; Wed, 4 Jan 2012 10:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uivm4+DZzH6o for ; Wed, 4 Jan 2012 10:36:41 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 30A7821F879F for ; Wed, 4 Jan 2012 10:36:40 -0800 (PST) Received: from [IPv6:2001:1488:ac14:1400:48b8:ae5c:60ce:4490] (unknown [IPv6:2001:1488:ac14:1400:48b8:ae5c:60ce:4490]) by mail.nic.cz (Postfix) with ESMTPSA id C87202A2AC2; Wed, 4 Jan 2012 19:36:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1325702199; bh=09ak+nCnWdbrdlgTUqi88/pokcMqZr5DD7IEwmX4LZo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=W+qDAPZRlOi7/hJV+GrvRq8KaK5KuhWMreeTg99uUIlQ3En0nhY4jWH2VTbu4Uo8z BvR6tNuSX/r27mm3grHmiqyf02JpukNhHd//2KEf4qVRm9oOO/E95h8QqiY4qkBzyk KknFU4SCEl8cCPKvyiNiZTw1kFrmAd5KcI7DZqp8= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Apple Message framework v1251.1) From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <20120104181709.GP13424@x27.adm.denic.de> Date: Wed, 4 Jan 2012 19:36:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <251E43BE-CC2A-468C-8A46-3002BC5D5D3B@nic.cz> References: <20120104181709.GP13424@x27.adm.denic.de> To: Peter Koch , dns-dir@ietf.org X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean X-Mailman-Approved-At: Tue, 10 Jan 2012 08:00:43 -0800 Subject: Re: [dns-dir] some comments on draft-os-ietf-sshfp-ecdsa-sha2-04.txt X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 18:36:42 -0000 Hi Peter, thanks for the review. I am preparing new revision based on last call and area secretariates comments, so I'll merge your comments as well. I am starting to find how unbelievably hard is to add just two new = numbers to IANA registry in IETF :). This draft will be soon in better shape than the one which actually did something (added support to SSH = protocol). O. On 4. 1. 2012, at 19:17, Peter Koch wrote: > Hi Ondrej, >=20 > i came across another review of = > and would like to add some remarks. I've copied the DNS Directorate > for information. Not sure what the status of the draft is - the > datatracker confuses me by claiming 'wg document', but i do not see > which WG? Generally the draft looks like a good idea! >=20 > To start with some formalities, the header and abstract claim the = draft > updates RFC 4255. I would suggest it does not. It updates two IANA > registries defined and seeded by RFC 4255, but it does not (to my > reading) change any content of RFC 4255. If it were to update 4255, > it should probably adjust the registry policies from "IETF consensus" > as per RFC 2434 to "IETF Review" as per RFC 5226, but that's probably > for another venue to discuss. >=20 > Second, the document aims at Standards Track and I do not see why. > An IETF/IESG reviewed RFC would be sufficient. Not saying it > should be less than ST, but what's the purpose here? Later serving > as normative reference? >=20 > In section 3.2 the use of an ECDSA fingerprint is defined. I could > not find the description of the Fingerprint in RFC 5656. > Furtheron it reads >=20 > ECDSA public key fingerprints MUST use the SHA-256 algorithm for the > fingerprint as using the SHA-1 algorithm would weaken the security = of > the key. >=20 > First, could the claim 'would weaken the security' be substantiated > (maybe by reference) a bit? Second, what is the consequence, i.e. > who is supposed to act on a violation? Is it the DNS implementation > (hard to achieve with 'transparent' RR types), the DNS operator or > the consuming entity? I would suggest to reverse the logic here and > only demand that a consuming party MUST ignore SHA-1 FPs for ECDSA. >=20 > In 4.1, the SHA-256 fingerprint is introduced. The consuming entity > is advised "Secure Shell > implementations which support SHA-256 fingerprints MUST prefer a = SHA- > 256 fingerprint over SHA-1 if both are available for a server. If > the SHA-256 fingerprint is tested and does not match the supplied > key, then the key MUST be rejected rather than testing the > alternative SHA-1 fingerprint." >=20 > This assumes that both FPs are for the same key? Couldn't it happen = that > the server offers an RSA and an ECDSA key, using SHA-1 for the former > and ECDSA for the latter? >=20 > Nit: Add some text after the headline "5. Examples", e.g. >=20 > The following examples provide reference for both the newly defined > ECDSA algorithm number and the use of the SHA-256 fingerprint > combined with both the new and the existing algorithm numbers. >=20 > The examples refer to "OpenSSH format" without any reference. >=20 > The references to the DNSSEC RFCs are probably informative only. >=20 > Best regards, > Peter -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From dromasca@avaya.com Fri Jan 13 02:57:43 2012 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 691FD21F8608; Fri, 13 Jan 2012 02:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.27 X-Spam-Level: X-Spam-Status: No, score=-103.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5dvGifsDtjt; Fri, 13 Jan 2012 02:57:42 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5F19A21F85F1; Fri, 13 Jan 2012 02:57:36 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOwNEE+HCzI1/2dsb2JhbABChRCnDXuBBYFyAQEBAQMSEQ0EPhMGAQgNCAUCBgYMCwECAgMBRAcBBgQBBAESCBqjZYlykTgEgS+JWDNjBJsFjE0 X-IronPort-AV: E=Sophos;i="4.71,503,1320642000"; d="scan'208";a="286058423" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Jan 2012 05:57:33 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Jan 2012 05:44:17 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 13 Jan 2012 11:57:29 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the January 19, 2012 IESG Teleconference Thread-Index: AczRfyPKxMIpSIkRRyG8ppVDEejZswAYbF3A From: "Romascanu, Dan (Dan)" To: , , "YANG Doctors" , , "IETF DNS Directorate" Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for the January 19, 2012 IESG Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 10:57:43 -0000 UGxlYXNlIGZpbmQgYmVsb3cgdGhlIHByZWxpbWluYXJ5IGFnZW5kYSBvZiB0aGUgMS8xOSBJRVNH IHRlbGVjaGF0LiBQbGVhc2Ugc2VuZCB5b3VyIHF1ZXN0aW9ucywgY29tbWVudHMgYW5kIGNvbmNl cm5zIGFib3V0IHRoZSBkb2N1bWVudHMgYW5kIGNoYXJ0ZXIgYnJvdWdodCB1cCBmb3IgV0cgYXBw cm92YWwgYmVmb3JlIFdlZG5lc2RheSAxLzE4IENPQi4gDQoNClRoYW5rcyBhbmQgUmVnYXJkcywN Cg0KRGFuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaWVzZy1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86aWVzZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg SUVTRyBTZWNyZXRhcnkNCg0KDQoyLiBQcm90b2NvbCBBY3Rpb25zDQoyLjEgV0cgU3VibWlzc2lv bnMNCjIuMS4xIE5ldyBJdGVtcw0KDQogIG8gZHJhZnQtaWV0Zi1tYXJmLXJlZGFjdGlvbi0wNA0K ICAgIFJlZGFjdGlvbiBvZiBQb3RlbnRpYWxseSBTZW5zaXRpdmUgRGF0YSBmcm9tIE1haWwgQWJ1 c2UgUmVwb3J0cw0KICAgIChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBUb2tlbjogUGV0ZSBSZXNu aWNrDQoNCiAgbyBkcmFmdC1pZXRmLW1hcmYtYXV0aGZhaWx1cmUtcmVwb3J0LTA5DQogICAgQXV0 aGVudGljYXRpb24gRmFpbHVyZSBSZXBvcnRpbmcgdXNpbmcgdGhlIEFidXNlIFJlcG9ydCBGb3Jt YXQNCiAgICAoUHJvcG9zZWQgU3RhbmRhcmQpDQogICAgVG9rZW46IFBldGUgUmVzbmljaw0KDQog IG8gZHJhZnQtaWV0Zi1uZXRleHQtcmFkaXVzLXBtaXA2LTA2DQogICAgUkFESVVTIFN1cHBvcnQg Zm9yIFByb3h5IE1vYmlsZSBJUHY2IChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBCYXNh dmFyYWogUGF0aWwgKEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20pIGlzIHRoZSBkb2N1bWVudA0K ICAgIHNoZXBoZXJkLg0KICAgIFRva2VuOiBKYXJpIEFya2tvDQoNCiAgbyBkcmFmdC1pZXRmLW5l dGV4dC1idWxrLXJlLXJlZ2lzdHJhdGlvbi0xMA0KICAgIEJ1bGsgQmluZGluZyBVcGRhdGUgU3Vw cG9ydCBmb3IgUHJveHkgTW9iaWxlIElQdjYgKFByb3Bvc2VkDQogICAgU3RhbmRhcmQpDQogICAg Tm90ZTogQmFzYXZhcmFqIFBhdGlsIChCYXNhdmFyYWouUGF0aWxAbm9raWEuY29tKSBpcyB0aGUg ZG9jdW1lbnQNCiAgICBzaGVwaGVyZC4NCiAgICBUb2tlbjogSmFyaSBBcmtrbw0KDQogIG8gZHJh ZnQtaWV0Zi1vc3BmLW11bHRpLWluc3RhbmNlLTA3DQogICAgT1NQRiBNdWx0aS1JbnN0YW5jZSBF eHRlbnNpb25zIChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBNYW5hdiBCaGF0aWEgKG1h bmF2LmJoYXRpYUBhbGNhdGVsLWx1Y2VudC5jb20pIGlzIHRoZSBkb2N1bWVudA0KICAgIHNoZXBo ZXJkLg0KICAgIFRva2VuOiBTdGV3YXJ0IEJyeWFudA0KDQogIG8gZHJhZnQtaWV0Zi1raXR0ZW4t c2FzbC1zYW1sLTA4DQogICAgQSBTQVNMIGFuZCBHU1MtQVBJIE1lY2hhbmlzbSBmb3IgU0FNTCAo UHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90ZTogVGhlIGRvY3VtZW50IHNoZXBoZXJkIGZvciB0 aGlzIGRvY3VtZW50IGlzIFNoYXduIEVtZXJ5DQogICAgKHNoYXduLmVtZXJ5QG9yYWNsZS5jb20p Lg0KICAgIFRva2VuOiBTdGVwaGVuIEZhcnJlbGwNCg0KICBvIGRyYWZ0LWlldGYtaWRyLWZzbS1z dWJjb2RlLTAyDQogICAgU3ViY29kZXMgZm9yIEJHUCBGaW5pdGUgU3RhdGUgTWFjaGluZSBFcnJv ciAoUHJvcG9zZWQgU3RhbmRhcmQpDQogICAgTm90ZTogU3VzYW4gSGFyZXMgaXMgdGhlIGRvY3Vt ZW50IHNoZXBoZXJkDQogICAgKFN1c2FuLkhhcmVzQGh1YXdlaS5jb20gb3Igc2hhcmVzQG5kemgu Y29tKS4NCiAgICBUb2tlbjogU3Rld2FydCBCcnlhbnQNCg0KICBvIGRyYWZ0LWlldGYtbWlsZS1y ZmM2MDQ2LWJpcy0wNQ0KICAgIFRyYW5zcG9ydCBvZiBSZWFsLXRpbWUgSW50ZXItbmV0d29yayBE ZWZlbnNlIChSSUQpIE1lc3NhZ2VzIG92ZXINCiAgICBIVFRQLyBUTFMgKFByb3Bvc2VkIFN0YW5k YXJkKQ0KICAgIE5vdGU6IEthdGhsZWVuIE1vcmlhcnR5IChrYXRobGVlbi5tb3JpYXJ0eUBlbWMu Y29tKSBpcyB0aGUgZG9jdW1lbnQNCiAgICBzaGVwaGVyZC4NCiAgICBUb2tlbjogU2VhbiBUdXJu ZXINCg0KICBvIGRyYWZ0LWlldGYtbWlsZS1yZmM2MDQ1LWJpcy0wNQ0KICAgIFJlYWwtdGltZSBJ bnRlci1uZXR3b3JrIERlZmVuc2UgKFJJRCkgKFByb3Bvc2VkIFN0YW5kYXJkKQ0KICAgIE5vdGU6 IEJyaWFuIFRyYW1tZWxsICh0cmFtbWVsbEB0aWsuZWUuZXRoei5jaCkgaXMgdGhlIGRvY3VtZW50 DQogICAgc2hlcGhlcmQuDQogICAgVG9rZW46IFNlYW4gVHVybmVyDQoNCjIuMS4yIFJldHVybmlu ZyBJdGVtcw0KDQogIE5PTkUNCg0KMi4yIEluZGl2aWR1YWwgU3VibWlzc2lvbnMNCjIuMi4xIE5l dyBJdGVtcw0KDQogIE5PTkUNCg0KMi4yLjIgUmV0dXJuaW5nIEl0ZW1zDQoNCiAgTk9ORQ0KDQoz LiBEb2N1bWVudCBBY3Rpb25zDQozLjEgV0cgU3VibWlzc2lvbnMNCjMuMS4xIE5ldyBJdGVtcw0K DQogIG8gZHJhZnQtaWV0Zi1saXNwLW1hcC12ZXJzaW9uaW5nLTA2DQogICAgTElTUCBNYXAtVmVy c2lvbmluZyAoRXhwZXJpbWVudGFsKQ0KICAgIE5vdGU6IFRlcnJ5IE1hbmRlcnNvbiAodGVycnku bWFuZGVyc29uQGljYW5uLm9yZykgaXMgdGhlIGRvY3VtZW50DQogICAgc2hlcGhlcmQuDQogICAg VG9rZW46IEphcmkgQXJra28NCiAgICBXYXMgZGVmZXJyZWQgYnkgQWRyaWFuIEZhcnJlbCBvbiAy MDExLTA5LTIxDQoNCjMuMS4yIFJldHVybmluZyBJdGVtcw0KDQogIG8gZHJhZnQtaWV0Zi1saXNw LTE5DQogICAgTG9jYXRvci9JRCBTZXBhcmF0aW9uIFByb3RvY29sIChMSVNQKSAoRXhwZXJpbWVu dGFsKQ0KICAgIE5vdGU6IEpvZWwgSGFscGVybiAoam1oQGpvZWxoYWxwZXJuLmNvbSkgaXMgdGhl IGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBKYXJpIEFya2tvDQoNCiAgbyBkcmFmdC1p ZXRmLWxpc3AtbXVsdGljYXN0LTEyDQogICAgTElTUCBmb3IgTXVsdGljYXN0IEVudmlyb25tZW50 cyAoRXhwZXJpbWVudGFsKQ0KICAgIE5vdGU6IFdhc3NpbSBIYWRkYWQgPHdhc3NpbS5oYWRkYWRA ZXJpY3Nzb24uY29tPiBpcyB0aGUNCiAgICBkb2N1bWVudCBzaGVwaGVyZC4NCiAgICBUb2tlbjog SmFyaSBBcmtrbw0KDQozLjIgSW5kaXZpZHVhbCBTdWJtaXNzaW9ucyBWaWEgQUQNCjMuMi4xIE5l dyBJdGVtcw0KDQogIG8gZHJhZnQta29tcGVsbGEtbDJ2cG4tbDJ2cG4tMDgNCiAgICBMYXllciAy IFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3JrcyBVc2luZyBCR1AgZm9yIEF1dG8tZGlzY292ZXJ5IGFu ZA0KICAgIFNpZ25hbGluZyAoSW5mb3JtYXRpb25hbCkNCiAgICBOb3RlOiBSb3NzIENhbGxvbiAo cmNhbGxvbkBqdW5pcGVyLm5ldCkgaXMgdGhlIGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2Vu OiBTdGV3YXJ0IEJyeWFudA0KDQogIG8gZHJhZnQtYXNoLWdjYWMtYWxnb3JpdGhtLXNwZWMtMDMN CiAgICBHZW5lcmljIENvbm5lY3Rpb24gQWRtaXNzaW9uIENvbnRyb2wgKEdDQUMpIEFsZ29yaXRo bSBTcGVjaWZpY2F0aW9uDQogICAgZm9yIElQL01QTFMgTmV0d29ya3MgKEV4cGVyaW1lbnRhbCkN CiAgICBOb3RlOiBZb3VuZyBMZWUgKGxlZXlvdW5nQGh1YXdlaS5jb20pIGlzIHRoZSBkb2N1bWVu dCBzaGVwaGVyZC4NCiAgICBUb2tlbjogQWRyaWFuIEZhcnJlbA0KDQogIG8gZHJhZnQtamlhbmct YTYtdG8taGlzdG9yaWMtMDANCiAgICBNb3ZpbmcgQTYgdG8gSGlzdG9yaWMgU3RhdHVzIChJbmZv cm1hdGlvbmFsKQ0KICAgIE5vdGU6IFJhbHBoIERyb21zIChyZHJvbXNAY2lzY28uY29tKSBpcyB0 aGUgZG9jdW1lbnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFJhbHBoIERyb21zDQoNCiAgbyBkcmFm dC15ZXZzdGlmZXlldi1kaXNjbG9zdXJlLXJlbGF0aW9uLTAyDQogICAgVGhlICdkaXNjbG9zdXJl JyBMaW5rIFJlbGF0aW9uIFR5cGUgKEluZm9ybWF0aW9uYWwpDQogICAgTm90ZTogVGhlIElFVEYg TGFzdCBDYWxsIGVuZHMgb24gSmFudWFyeSA2Lg0KICAgIFRva2VuOiBQZXRlciBTYWludC1BbmRy ZQ0KICAgIFdhcyBkZWZlcnJlZCBieSBQZXRlciBTYWludC1BbmRyZSBvbiAyMDEyLTAxLTAzDQoN CjMuMi4yIFJldHVybmluZyBJdGVtcw0KDQogIE5PTkUNCg0KMy4zIElSVEYgYW5kIEluZGVwZW5k ZW50IFN1Ym1pc3Npb24gU3RyZWFtIERvY3VtZW50cw0KMy4zLjEgTmV3IEl0ZW1zDQoNCiAgTk9O RQ0KDQozLjMuMiBSZXR1cm5pbmcgSXRlbXMNCg0KICBOT05FDQoNCjQuIFdvcmtpbmcgR3JvdXAg QWN0aW9ucw0KNC4xIFdHIENyZWF0aW9uDQo0LjEuMSBQcm9wb3NlZCBmb3IgSUVURiBSZXZpZXcN Cg0KICBOT05FDQoNCjQuMS4yIFByb3Bvc2VkIGZvciBBcHByb3ZhbA0KDQogIE5PTkUNCg0KNC4y IFdHIFJlY2hhcnRlcmluZw0KNC4yLjEgVW5kZXIgRXZhbHVhdGlvbiBmb3IgSUVURiBSZXZpZXcN Cg0KICBOT05FDQoNCjQuMi4yIFByb3Bvc2VkIGZvciBBcHByb3ZhbA0KDQogIG8gTG9jYXRvci9J RCBTZXBhcmF0aW9uIFByb3RvY29sIChsaXNwKQ0KICAgIFRva2VuOiBKYXJpDQoNCiAgbyBEaWFt ZXRlciBNYWludGVuYW5jZSBhbmQgRXh0ZW5zaW9ucyAoZGltZSkNCiAgICBUb2tlbjogRGFuDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KKiBQ bGVhc2Ugc2VlIHRoZSBJRCBUcmFja2VyIChodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy8pIGZvcg0KZGV0YWlscyBvbiBkb2N1bWVudHMgdGhhdCBhcmUgdW5kZXIgZGlzY3Vzc2lvbiBi eSB0aGUgSUVTRy4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0K From rdroms.ietf@gmail.com Mon Jan 16 15:01:38 2012 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A360521F85E3 for ; Mon, 16 Jan 2012 15:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDll4OXJ9qUm for ; Mon, 16 Jan 2012 15:01:38 -0800 (PST) Received: from mail-qw0-f51.google.com (mail-qw0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 50AF621F84C8 for ; Mon, 16 Jan 2012 15:01:26 -0800 (PST) Received: by qadz32 with SMTP id z32so1177345qad.10 for ; Mon, 16 Jan 2012 15:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=HeH7nG8F/2Y8p8IUZYbqlqxfgeQCgUSSE5wUE/KSk2I=; b=xIWRDulUTm58A0pFp8XY+4hm1LK9WVQ+NY1SOrjlHiafW+efF8w++xfY2Nzm/PPdb/ YJ6pd9/JyzwzZn12RduUnkrVTJvzgoLIfjQipz0QTCk/Oz6/a95QJC6yXg7FlqAClVr4 KYQZtYimYkpjI0WhSLYwCTbnA5jDOmSBBOtR8= Received: by 10.224.187.20 with SMTP id cu20mr16979856qab.43.1326754885899; Mon, 16 Jan 2012 15:01:25 -0800 (PST) Received: from rtp-rdroms-8913.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id hv20sm39641921qab.22.2012.01.16.15.01.23 (version=SSLv3 cipher=OTHER); Mon, 16 Jan 2012 15:01:24 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Ralph Droms In-Reply-To: Date: Mon, 16 Jan 2012 18:01:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <41596C0C-A779-4421-A6B8-D53B3EC9C33C@gmail.com> References: To: IETF DNS Directorate X-Mailer: Apple Mail (2.1251.1) Subject: Re: [dns-dir] PRELIMINARY Agenda and Package for the January 19, 2012 IESG Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 23:01:38 -0000 DNS Directorate - I have two specific questions about this document on = this week's IESG agenda: o draft-jiang-a6-to-historic-00 Moving A6 to Historic Status (Informational) Note: Ralph Droms (rdroms@cisco.com) is the document shepherd. Token: Ralph Droms Two comments have been received about the document that I would like to = get your input on: =46rom the sec-dir review: * It is quite possible that some domains will continue to employ A6 domains as an administrative convenience, generating the corresponding AAAA records as required. This case needs more consideration from a security point of view. It would be useful to require that such records be ignored by applications and preferably be blocked from external view. Note: the authors have responded: We already recommend "Removing A6 handling from all new or updated host stacks" and we could add a recommendation for apps to ignore them. Blocking visibility of RRs is generally not something the DNS community likes, though. =46rom Adrian Farrel's Discuss: * Should the DNS record type 38 be deprecated (and marked so in the registry? Note: draft-jiang-a6-to-historic already includes the following text for = IANA: 6. IANA Considerations=20 IANA is requested to change the annotation of the A6 RR type from=20 "Experimental" to "Obsolete" in the DNS Parameters registry.=20 I see that several RR types have been marked as "Obsolete," but none = have been marked as either "Historic" (in keeping with the move of RFC = 2874 to Historic status) or "Deprecated." Any thoughts about the proper = new designation for RR type 38, A6? - Ralph From rdroms.ietf@gmail.com Mon Jan 16 16:06:32 2012 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2167921F8571 for ; Mon, 16 Jan 2012 16:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9d2x4aoo5OkS for ; Mon, 16 Jan 2012 16:06:31 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 60BE821F8565 for ; Mon, 16 Jan 2012 16:06:31 -0800 (PST) Received: by qcsc1 with SMTP id c1so2048943qcs.31 for ; Mon, 16 Jan 2012 16:06:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=+rpIYAkknwcAE7CDJUIOLvQIYwlATuAHIREwY9WrHfo=; b=Mhm+KA+HIuHMxNdMZsCyGoaiY/biMj+yc/uE2fO+621Z8fiKv1Uvk9AALY+klj53gH rLIfoGUgajCzMlO1vlSNzFteWc12wwTCSy+W2BV2uJlRDoNXB1NC0AJcJcpmHOpWJDIr QxWhZ/ptP5cWyKu5VqP/U+/VIPKjY01pjlKXw= Received: by 10.224.182.10 with SMTP id ca10mr17555094qab.1.1326758789911; Mon, 16 Jan 2012 16:06:29 -0800 (PST) Received: from rtp-rdroms-8913.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id eb5sm39998691qab.10.2012.01.16.16.06.28 (version=SSLv3 cipher=OTHER); Mon, 16 Jan 2012 16:06:29 -0800 (PST) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Jan 2012 19:06:27 -0500 Message-Id: To: IETF Directorate DNS Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: [dns-dir] Service "subtypes" X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 00:06:32 -0000 draft-ietf-nfsv4-federated-fs-dns-srv-namespace proposes the use of = subtypes of the service type "_nfs"; e.g.: _domainroot._nfs._tcp.example.com The use of subtypes is defined in draft-cheshire-dnsext-dns-sd = (currently in the RFC Ed queue), but not mentioned in RFC 2782 or RFC = 6335. I only see one reference to a "subtype" in the new service = registry, = http://www.iana.org/assignments/service-names-port-numbers/service-names-p= ort-numbers.xml Is there any reason to be uncomfortable with the = definition of the _domainroot subtype in = draft-ietf-nfsv4-federated-fs-dns-srv-namespace, as specified in the = IANA Considerations section of = draft-ietf-nfsv4-federated-fs-dns-srv-namespace? - Ralph From ajs@anvilwalrusden.com Mon Jan 16 22:07:46 2012 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336CD21F8531 for ; Mon, 16 Jan 2012 22:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyUG+1+Dihq7 for ; Mon, 16 Jan 2012 22:07:44 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 578B721F852F for ; Mon, 16 Jan 2012 22:07:44 -0800 (PST) Received: from crankycanuck.ca (unknown [100.44.91.115]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 6A7E41ECB420 for ; Tue, 17 Jan 2012 06:07:31 +0000 (UTC) Date: Tue, 17 Jan 2012 01:07:19 -0500 From: Andrew Sullivan To: IETF Directorate DNS Message-ID: <20120117060719.GA95054@crankycanuck.ca> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [dns-dir] Service "subtypes" X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 06:07:46 -0000 Yes, but I can't think of any principled way to do anything about it. We lost control of this means of extending the DNS ages ago. There have been attempts to set up a registry but the fact is that a multilayer hierarchy doesn't lend itself to anything except a flat registry, or else multiple delegations. We are reproducing the registration quirks in the DNS in an IANA registry. -- Andrew Sullivan Please excuse my clumsy thumbs. On 2012-01-16, at 19:06, Ralph Droms wrote: > draft-ietf-nfsv4-federated-fs-dns-srv-namespace proposes the use of subtypes of the service type "_nfs"; e.g.: > > _domainroot._nfs._tcp.example.com > > The use of subtypes is defined in draft-cheshire-dnsext-dns-sd (currently in the RFC Ed queue), but not mentioned in RFC 2782 or RFC 6335. I only see one reference to a "subtype" in the new service registry, http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml Is there any reason to be uncomfortable with the definition of the _domainroot subtype in draft-ietf-nfsv4-federated-fs-dns-srv-namespace, as specified in the IANA Considerations section of draft-ietf-nfsv4-federated-fs-dns-srv-namespace? > > - Ralph > > _______________________________________________ > dns-dir mailing list > dns-dir@ietf.org > https://www.ietf.org/mailman/listinfo/dns-dir From olaf@NLnetLabs.nl Wed Jan 25 02:18:37 2012 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD08421F8603; Wed, 25 Jan 2012 02:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.034 X-Spam-Level: X-Spam-Status: No, score=-103.034 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599, GB_I_LETTER=-2, MIME_8BIT_HEADER=0.3, SARE_OBFU_VALUE=0.525, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF0aLkQvGmmX; Wed, 25 Jan 2012 02:18:31 -0800 (PST) Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AAF21F85EF; Wed, 25 Jan 2012 02:18:30 -0800 (PST) Received: from [192.168.178.31] (peer.kolkman.org [82.95.132.144]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.4/8.14.4) with ESMTP id q0PAIMEp017063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 25 Jan 2012 11:18:23 +0100 (CET) (envelope-from olaf@NLnetLabs.nl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1327486706; bh=JiJwKR4+V0qJkgnI+vTvF0fNq6NubXMj+6KaAudmUlg=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date: Message-Id:References:To; b=LcF22M4kaso90IIdAzTRUsRRyewok5vifIM62vW1NvwkYpNmbNkRbRCP2X9pk99u+ EqrK2SOdtSHDFfA3Jjdp6hvL2jjBKveY2AG8oHXpfWQXk9g7slch0uSn9jjoWC6c/T 7Y5EKqwXOG0T3esu5zvOTmsTBJ2Jt9ReD2Cp3nyI= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/signed; boundary="Apple-Mail=_F4FC8F5D-E25D-44BF-B593-031A9B9B2B1F"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: Olaf Kolkman In-Reply-To: <24A3B7BC-B04C-49DB-B74C-88F94188328E@NLnetLabs.nl> Date: Wed, 25 Jan 2012 11:18:21 +0100 Message-Id: References: <9B57C850BB53634CACEC56EF4853FF653B3864AD@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <9E4C67D1-3CFD-460F-8E4A-108BAABAE202@NLnetLabs.nl> <563C00E3D04619AA02BC41F9@[192.168.1.128]> <93D5DA78-F6CD-40F4-8442-7809508CF528@NLnetLabs.nl> <20120120142004.GD4944@crankycanuck.ca> <2A7361A9-A813-4988-9E89-CA7270A418A1@NLnetLabs.nl> <1F7BB9A4-6348-4690-9161-07D9E3908DE5@NLnetLabs.nl> <7299338B-AD83-48E4-AC56-702475501F47@NLnetLabs.nl> <9D7456178744E49BD6844F45@PST.JCK.COM> <82E16398-BD16-4E97-AF55-6963C3FBB66D@NLnetLabs.nl> <12EA203C256A38F57E802D43@PST.JCK.COM> <796BE3EB-76FB-4818-A3D5-435AA132A230@NLnetLabs.nl> <0BCB4CEB-D8A4-4014-BD61-B5B39F6C2738@NLnetLabs.nl> <24A3B7BC-B04C-49DB-B74C-88F94188328E@NLnetLabs.nl> To: i18n@iab.org, iana-strategy@i1b.org, IETF DNS Directorate X-Mailer: Apple Mail (2.1251.1) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (open.nlnetlabs.nl [213.154.224.1]); Wed, 25 Jan 2012 11:18:24 +0100 (CET) Subject: [dns-dir] =?windows-1252?q?5th_draft=85_was_Re=3A_Comments_on_dra?= =?windows-1252?q?ft_=28was=3A_Re=3A__Browser_IDN_display_policy_etc=2E=29?= X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 10:18:37 -0000 --Apple-Mail=_F4FC8F5D-E25D-44BF-B593-031A9B9B2B1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [I am putting the DNS directorate in the loop, the introduction is for = them] Colleagues, This is the fifth and hopefully final draft of a statement developed = with input from IAB's i18n and iana-strategy program. It is about to be = sent to the IAB with a recommendation for approval. The note should be self-explanatory. But, shortly, its intend is to = communicate that other considerations than purely DNS protocol = considerations exists when deciding which labels to allow. During the directory dinner in Taipei we discussed the aspect of numbers = that might be interpreted by some implementations as IP addresses and = this statement calls out that some research is needed in that area even = when we want to provide the most liberal interpretation of the general = requirements. Anyhow, I am sharing this with you all since I wouldn't want you to be = caught by surprise and although feedback from the directorate is = certainly no requirement, there is a small window of opportunity if you = would want to provided feedback. --Olaf 5th DRAFT IAB statement on "The interpretation of rules in the ICANN gTLD Applicants Guidebook." =3D Introduction The IAB observes that the ICANN gTLD Applicants Guidebook (version 2012-01-11) contains a section with requirements for Internationalized Domain Names (IDNs) in section 1.3. This section contains the following requirement: "The prefix and string together must conform to all requirements for a label that can be stored in the DNS including conformance to the LDH (host name) rule described in RFC 1034, RFC 1123, and elsewhere." The IAB maintains the following interpretation of that requirement. Top-Level and Second-Level Domain (TLD and SLD) labels in the Domain Name System (DNS) [RFC1034] [RFC1035] are not required by the DNS protocols to adhere to any syntax beyond that for any other DNS label: e.g. any binary string whatever can be used at any point in the DNS [RFC2181]. However there are good engineering reasons, some of them embedded into application protocols, for providing the more restricted Letter-Digit-Hyphen(LDH) syntax. While to a substantial degree policy matters related to the DNS lie with ICANN, a base syntax constraint for SLD and TLD labels, with its roots in protocol engineering and operations, is a natural product of the IETF and has been an IAB responsibility since its early existence. Such syntax definitions form a baseline upon which other DNS policy can be layered. One of the documents that the guidebook explicitly referred to is RFC1123. In conversations with subject matter specialists we have observed different interpretations about the normative nature of one of the specific TLD requirements set by that document ('will be alphabetic' see discussion below). However, that specific RFC 1123 requirement reflects policy choices set by the IAB in pre-ICANN times that were informed by the application-layer considerations relating to human factors. =3D Technical Detail [RFC1034] provides the definition of a preferred name syntax in section 3.5 with the following motivation: "However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs." The document then continues with an example referring to names as used by the Internet Mail application and the rules for the old HOSTS.TXT file (see [RFC952] for context). The section finishes with the exact specification of the LDH in Abstract Syntax notation. [RFC1123] reaffirms this definition, but makes one change to the syntax: 'The syntax of a legal Internet host name was specified in RFC-952 [DNS:4]. One aspect of host name syntax is hereby changed: the restriction on the first character is relaxed to allow either a letter or a digit. Host software MUST support this more liberal syntax.' [Section 2.1] In addition, the DISCUSSION section of Section 2.1 says: 'However, a valid host name can never have the dotted-decimal form #.#.#.#, since at least the highest-level component label will be alphabetic.' [Section 2.1] Neither [RFC0952] nor [RFC1123] explicitly states the reasons for these restrictions. But, prudent engineering so that human factors, such as confusion, cause minimal problems are an important consideration. For instance, [RFC1123] suggest that one of the reasons was to prevent confusion between dotted-decimal IPv4 addresses and host domain names. That decision has been interpreted as normative and is known to have found its way in specifications, implementations, or both. For instance [RFC1738], in its description of the "host" part of a Uniform Resource Locator, declares: 'The rightmost domain label will never start with a digit, though, which syntactically distinguishes all domain names from the IP addresses.' [Section 3.1] Summarizing, the restriction that 'the highest-level component label will be alphabetic' has been assumed in some deployed software, and therefore changes to the rules should be undertaken with caution. The strictest interpretation of 'will be alphabetic' would exclude valid A-Labels in the root and should be expanded to permit the xn-- type labels. We are aware of at least one work in progress [draft-liman-tld-names] that is trying to provide such an expanded specification. We assert that the following requirements apply to any such specification: 1. TLD labels that do not allow IPv4 and IPv6 address literals to be clearly distinguishable from DNS names, both in wire and presentation format, MUST NOT be permitted. (This is the most liberal requirement.) 2. Internationalised strings encoded according to the IDNA2008 specification [RFC5891] [RFC5892] MUST be permitted in general, but the set of Unicode characters which are permissible in TLD U-Labels MAY be constrained in order to satisfy other requirements. (The most conservative interpretation of this constraint is the "only alphabetic requirement".) 3. Existing TLD labels at the time this document is published MUST be permitted. 4. The syntax definition SHOULD be compatible with existing assumptions by application developers and users, to the extent that those assumptions can be determined. Indeed, when translating the RFC1123 requirement to a specification, pure technical as well as human factors (requirement 4) need to be taken into account in the engineering. The resulting specification is likely to end up between two extreme interpretations: The first takes the most conservative interpretation and translates that specification to the IDN context, and the second takes the most liberal boundary, which only defines the known technical limitations (ignoring the human factors). The most conservative interpretation of the constrains set by RFC1123 is that a TLD is 'alphabetic' only. The specification of this interpretation in the context to IDNA would not allow numbers, symbols such as punctuation marks, or diactrics in both A and U-Label with the notable exception of the 'xn--' construct in A-Labels.=20 The most liberal interpretation of RFC1123 would be a specification whereby requirement 4 does not introduce limitations that are not already set by the other 3 requirements. Such specification would define the input vallues in such a way that the final label cannot contain an element that can be interpreted as part of an IP address. Examples of those are labels consisting of strings that represent integers between expressed in decimal, octal, or hexadecimal but also U-labels that are likely to be interpreted as numbers by OS or application libraries when entered in the user interface. To provide the specification for the most liberal interpretation, research is needed as to how user input is eventually interpreted as purely numeric and a possible IP address in legacy network stacks and applications. A final specification is likely to end up between these two extremes as it also takes human factors and implementation issues from requirement 4 into account. For example, combining Unicode characters from the general letter category with the general mark category (specifically the 'Mark, spacing combined' category [UNICODE61]) might cause script dependencies in rendering libraries which creates complexities that might eventually result in increased likelihood of confusion among strings that would not be confused if rendered correctly. It is not a given that these problems will happen but is currently a subject of study among implementers and subject matter specialists. While a detailed specification is pending we recommend DNS registries, ICANN in particular, follow the most conservative approach with respect to the constraints set by other requirements i.e. issues like usability, confusability, stability etc. The most conservative approach is that one set by the 'will be alphabetic' text in RFC1123 translated to internationalized context: 1. the DNS-Label is a valid IDNA-valid string according to = [RFC5890]; 2. the derived property value of all code points, as defined by [RFC5890], is PVALID; 3. the general category of all code points, is one of {Ll, Lo, Lm}. [UNICODE61] Although this conservative constraint doesn't prevent useful mnemonics it is clear that not including the Mn and Mc general capacities limits the possibility of full expression for certain South Eastern Asian scripts. However, introducing labels that can cause interoperability issues and/or set false expectations from users of the Internet will be more damaging than following a conservative approach; The Internet does not have an 'undo' button. Summarizing For the restrictions on TLD labels the ICANN GTLd guidebook makes a reference to RFCs that contain technical policy choices that have not been translated to internationalized versions. Research on existing implementations, user-, and applications interfaces is needed before a detailed specification can be developed. Absence such specification the IAB strongly recommends a conservative approach in allowing new TLD delegations. The IAB, January XXX, 2012. References [draft-liman-tld-names]: L-J. Liman and J. Abley "Top Level Domain Name Specification", http://tools.ietf.org/html/draft-liman-tld-names-06 (work in progress, last checked Jan 24, 2012) [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010. [RFC5892] Faltstrom, P., "The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)", RFC 5892, August 2010. [Unicode60] The Unicode Consortium. The Unicode Standard, Version 6.0.0, defined by: "The Unicode Standard, Version 6.0.0", (Mountain View, CA: The Unicode Consortium, 2011. ISBN 978-1-936213-01-6). . ________________________________________________________=20 Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ =20 --Apple-Mail=_F4FC8F5D-E25D-44BF-B593-031A9B9B2B1F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBAgAGBQJPH9btAAoJEFRqER47aqpkjEsQAIeYoOBN8En3EIaNBGdwKcsL YEZtXX/5TOAGKjX10blGNw3sWQBxw1KycfjtikxX3aJ2ZjRn2ckYKimwE+vHzQkr 2Nxd/zHI1ITLrlxLmsB55//vtpWZK119MLrxpmElrPPOZlX20mTu3I6US3XQkXsl Go6MslMRFpSIoFST8uaXvlTACyH2GcLQwwgRWGV2xyASkmTTUIZTNvdtyl9oVtlV csqFwO4iwwONQIKbNXbBXqmLDU+qGfFr4TxKOeK9RW5RgxU/x1iY3jC87ixYTHXF Jf/48+T1ZUHSCd5988nLGMBrpkNV/gWAimi7Qpays7riwhuH/cjgJ0SfaC2mXMJO Onwoq7f7CvkKXDLN85RXD8HXlSQ/tE8in+u6qUC6pgKIYl+mKLev2MMnC8davvM3 MUFFvN9k2KGCD5ahe6ixQkKHj1gKhny3E/nTXHVWYP1o04t6sWhdi9UT+vVJFaNz i6wwX+pwJMvpo/+aoNSpNGd9nHGxumUSpZ2iKqdHKFeZuBhYTDsR44tDnwNYd558 mwTpFius87XObkGGzOU5iljUJ8iqr5LTQJDIAA8DYU/ex4uqekLGPXSSzcRsp+HN qk/IW9c5RMKEiGV8rY5dIm7nzZLJAA5tqyLiTkLbWrBeF41U+Ajj5+c7L/Z41Pv2 XWEB6upUqxNyI0GbaODd =WsFi -----END PGP SIGNATURE----- --Apple-Mail=_F4FC8F5D-E25D-44BF-B593-031A9B9B2B1F-- From stpeter@stpeter.im Wed Jan 25 07:27:44 2012 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A208621F8661 for ; Wed, 25 Jan 2012 07:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=-0.372, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKcGbT8XD9IU for ; Wed, 25 Jan 2012 07:27:44 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1C10021F858F for ; Wed, 25 Jan 2012 07:27:44 -0800 (PST) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 22A9340058; Wed, 25 Jan 2012 08:37:28 -0700 (MST) Message-ID: <4F201F6D.20905@stpeter.im> Date: Wed, 25 Jan 2012 08:27:41 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Olaf Kolkman References: <9B57C850BB53634CACEC56EF4853FF653B3864AD@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <9E4C67D1-3CFD-460F-8E4A-108BAABAE202@NLnetLabs.nl> <563C00E3D04619AA02BC41F9@[192.168.1.128]> <93D5DA78-F6CD-40F4-8442-7809508CF528@NLnetLabs.nl> <20120120142004.GD4944@crankycanuck.ca> <2A7361A9-A813-4988-9E89-CA7270A418A1@NLnetLabs.nl> <1F7BB9A4-6348-4690-9161-07D9E3908DE5@NLnetLabs.nl> <7299338B-AD83-48E4-AC56-702475501F47@NLnetLabs.nl> <9D7456178744E49BD6844F45@PST.JCK.COM> <82E16398-BD16-4E97-AF55-6963C3FBB66D@NLnetLabs.nl> <12EA203C256A38F57E802D43@PST.JCK.COM> <796BE3EB-76FB-4818-A3D5-435AA132A230@NLnetLabs.nl> <0BCB4CEB-D8A4-4014-BD61-B5B39F6C2738@NLnetLabs.nl> <24A3B7BC-B04C-49DB-B74C-88F94188328E@NLnetLabs.nl> In-Reply-To: X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 25 Jan 2012 08:00:50 -0800 Cc: iana-strategy@i1b.org, i18n@iab.org, IETF DNS Directorate Subject: Re: [dns-dir] =?utf-8?b?W2kxOG5dIDV0aCBkcmFmdOKApiB3YXMgUmU6IENvbW1l?= =?utf-8?q?nts_on_draft?= X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 15:27:44 -0000 On 1/25/12 3:18 AM, Olaf Kolkman wrote: > Summarizing, the restriction that 'the highest-level component label > will be alphabetic' has been assumed in some deployed software, > and therefore changes to the rules should be undertaken with caution. The phrase "changes to the rules should be undertaken with caution" might be read as "we should make changes to the rules, but do so carefully". I suggest: "caution should be exercised when contemplating any changes to the rules" (or somesuch). Peter -- Peter Saint-Andre https://stpeter.im/ From dromasca@avaya.com Fri Jan 27 10:31:56 2012 Return-Path: X-Original-To: dns-dir@ietfa.amsl.com Delivered-To: dns-dir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511B521F8670; Fri, 27 Jan 2012 10:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.084 X-Spam-Level: X-Spam-Status: No, score=-103.084 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+1mWPFXjXFK; Fri, 27 Jan 2012 10:31:55 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 770FC21F863F; Fri, 27 Jan 2012 10:31:55 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAInsIk/GmAcF/2dsb2JhbABEhQuoTXqBBYFyAQEBAQMSEQ0EUQYBCA0IAQQCBgYMCwECAgMBRAcBBgQBBAESCBqkIolykV+BL4diASQGNReCbhMOgSgMFYIYM2MEmxOMVQ X-IronPort-AV: E=Sophos;i="4.71,581,1320642000"; d="scan'208";a="326899254" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 27 Jan 2012 13:31:54 -0500 Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 27 Jan 2012 13:26:38 -0500 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 27 Jan 2012 19:31:52 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRELIMINARY Agenda and Package for the February 2, 2012 IESG Teleconference Thread-Index: AczcgOtnocb/4tTnShaVT1QxqpbivQAoLXfg From: "Romascanu, Dan (Dan)" To: , , "IETF DNS Directorate" , "YANG Doctors" , Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for the February 2, 2012 IESG Teleconference X-BeenThere: dns-dir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: IETF DNS directorate discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 18:31:56 -0000 UGxlYXNlIGZpbmQgYmVsb3cgdGhlIHByZWxpbWluYXJ5IGFnZW5kYSBvZiB0aGUgSUVTRyB0ZWxl Y2hhdCBvbiAyLzIuIFBsZWFzZSBzZW5kIG1lIHlvdXIgcXVlc3Rpb25zLCBjb21tZW50cyBvciBj b25jZXJucyBhYm91dCB0aGUgaXRlbXMgb24gdGhlIGFnZW5kYSBiZWZvcmUgV2VkbmVzZGF5IDIv MSBDT0IuIA0KDQpUaGFua3MgYW5kIFJlZ2FyZHMsDQoNCkRhbg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBpZXNnLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppZXNnLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJRVNHIFNlY3JldGFyeQ0KU2VudDogRnJpZGF5 LCBKYW51YXJ5IDI3LCAyMDEyIDE6MTkgQU0NCi4uLg0KDQoyLiBQcm90b2NvbCBBY3Rpb25zDQoy LjEgV0cgU3VibWlzc2lvbnMNCjIuMS4xIE5ldyBJdGVtcw0KDQogIG8gZHJhZnQtaWV0Zi1zaWRy LXJwa2ktcnRyLTI0DQogICAgVGhlIFJQS0kvUm91dGVyIFByb3RvY29sIChQcm9wb3NlZCBTdGFu ZGFyZCkNCiAgICBOb3RlOiBEb2N1bWVudCBzaGVwaGVyZCBpcyBDaHJpcyBNb3Jyb3cgKG1vcnJv d2NAb3BzLW5ldG1hbi5uZXQpLg0KICAgIFRva2VuOiBTdGV3YXJ0IEJyeWFudA0KDQoyLjEuMiBS ZXR1cm5pbmcgSXRlbXMNCg0KICBvIGRyYWZ0LWlldGYtcm10LXNpbXBsZS1hdXRoLWZvci1hbGMt bm9ybS0wNg0KICAgIFNpbXBsZSBBdXRoZW50aWNhdGlvbiBTY2hlbWVzIGZvciB0aGUgQUxDIGFu ZCBOT1JNIFByb3RvY29scw0KICAgIChQcm9wb3NlZCBTdGFuZGFyZCkNCiAgICBOb3RlOiBCcmlh biBBZGFtc29uIChhZGFtc29uQGl0ZC5ucmwubmF2eS5taWwpIGlzIHRoZSBkb2N1bWVudA0KICAg IHNoZXBoZXJkLg0KICAgIFRva2VuOiBEYXZpZCBIYXJyaW5ndG9uDQoNCjIuMiBJbmRpdmlkdWFs IFN1Ym1pc3Npb25zDQoyLjIuMSBOZXcgSXRlbXMNCg0KICBvIGRyYWZ0LW5vdHRpbmdoYW0taHR0 cC1uZXctc3RhdHVzLTAzDQogICAgQWRkaXRpb25hbCBIVFRQIFN0YXR1cyBDb2RlcyAoUHJvcG9z ZWQgU3RhbmRhcmQpDQogICAgVG9rZW46IFBldGVyIFNhaW50LUFuZHJlDQoNCjIuMi4yIFJldHVy bmluZyBJdGVtcw0KDQogIE5PTkUNCg0KMy4gRG9jdW1lbnQgQWN0aW9ucw0KMy4xIFdHIFN1Ym1p c3Npb25zDQozLjEuMSBOZXcgSXRlbXMNCg0KICBvIGRyYWZ0LWlldGYtdjZvcHMtaXB2Ni1kaXNj YXJkLXByZWZpeC0wMg0KICAgIEEgRGlzY2FyZCBQcmVmaXggZm9yIElQdjYgKEluZm9ybWF0aW9u YWwpDQogICAgTm90ZTogSm9lbCBKYWVnZ2xpLCAoam9lbGphQGJvZ3VzLmNvbSkgdjZvcHMgY28t Y2hhaXIsIGlzIHRoZQ0KICAgIGRvY3VtZW50IHNoZXBoZXJkLg0KICAgIFRva2VuOiBSb24gQm9u aWNhDQoNCiAgbyBkcmFmdC1pZXRmLTZtYW4tMzYyNy1oaXN0b3JpYy0wMQ0KICAgIFJGQzM2Mjcg dG8gSGlzdG9yaWMgc3RhdHVzIChJbmZvcm1hdGlvbmFsKQ0KICAgIE5vdGU6IEJyaWFuIEhhYmVy bWFuIChicmlhbkBpbm5vdmF0aW9uc2xhYi5uZXQpIGlzIHRoZSBkb2N1bWVudA0KICAgIHNoZXBo ZXJkLg0KICAgIFRva2VuOiBKYXJpIEFya2tvDQoNCiAgbyBkcmFmdC1pZXRmLXJhZGV4dC1yYWRz ZWMtMTANCiAgICBUTFMgZW5jcnlwdGlvbiBmb3IgUkFESVVTIChFeHBlcmltZW50YWwpDQogICAg Tm90ZTogSm91bmkgS29yaG9uZW4gKGpvdW5pLmtvcmhvbmVuQG5zbi5jb20pIGlzIHRoZSBEb2N1 bWVudA0KICAgIFNoZXBoZXJkLg0KICAgIFRva2VuOiBEYW4gUm9tYXNjYW51DQoNCjMuMS4yIFJl dHVybmluZyBJdGVtcw0KDQogIG8gZHJhZnQtaWV0Zi12Nm9wcy12Ni1hYWFhLXdoaXRlbGlzdGlu Zy1pbXBsaWNhdGlvbnMtMDgNCiAgICBDb25zaWRlcmF0aW9ucyBmb3IgVHJhbnNpdGlvbmluZyBD b250ZW50IHRvIElQdjYgKEluZm9ybWF0aW9uYWwpDQogICAgTm90ZTogSm9lbCBKYWVnZ2xpIChq b2VsamFAYm9ndXMuY29tKSBpcyB0aGUgZG9jdW1lbnQgc2hlcGhlcmQuDQogICAgVG9rZW46IFJv biBCb25pY2ENCg0KMy4yIEluZGl2aWR1YWwgU3VibWlzc2lvbnMgVmlhIEFEDQozLjIuMSBOZXcg SXRlbXMNCg0KICBOT05FDQoNCjMuMi4yIFJldHVybmluZyBJdGVtcw0KDQogIE5PTkUNCg0KMy4z IElSVEYgYW5kIEluZGVwZW5kZW50IFN1Ym1pc3Npb24gU3RyZWFtIERvY3VtZW50cw0KMy4zLjEg TmV3IEl0ZW1zDQoNCiAgTk9ORQ0KDQozLjMuMiBSZXR1cm5pbmcgSXRlbXMNCg0KICBOT05FDQoN CjQuIFdvcmtpbmcgR3JvdXAgQWN0aW9ucw0KNC4xIFdHIENyZWF0aW9uDQo0LjEuMSBQcm9wb3Nl ZCBmb3IgSUVURiBSZXZpZXcNCg0KICBOT05FDQoNCjQuMS4yIFByb3Bvc2VkIGZvciBBcHByb3Zh bA0KDQogIE5PTkUNCg0KNC4yIFdHIFJlY2hhcnRlcmluZw0KNC4yLjEgVW5kZXIgRXZhbHVhdGlv biBmb3IgSUVURiBSZXZpZXcNCg0KICBvIE5FVENPTkYgRGF0YSBNb2RlbGluZyBMYW5ndWFnZSAo bmV0bW9kKQ0KICAgIFRva2VuOiBEYW4NCg0KICBvIEJhc2ljIExldmVsIG9mIEludGVyb3BlcmFi aWxpdHkgZm9yIFNJUCBTZXJ2aWNlcyAoYmxpc3MpDQogICAgVG9rZW46IFJvYmVydA0KDQogIG8g QmlEaXJlY3Rpb25hbCBvciBTZXJ2ZXItSW5pdGlhdGVkIEhUVFAgKGh5YmkpDQogICAgVG9rZW46 IFBldGVyDQoNCjQuMi4yIFByb3Bvc2VkIGZvciBBcHByb3ZhbA0KDQogIG8gTG9jYXRvci9JRCBT ZXBhcmF0aW9uIFByb3RvY29sIChsaXNwKQ0KICAgIFRva2VuOiBKYXJpDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KDQoNCg==