Re: [regext] AD review of draft-ietf-regext-unhandled-namespaces-06
"Gould, James" <jgould@verisign.com> Tue, 26 January 2021 18:40 UTC
Return-Path: <jgould@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A4F3A0D47; Tue, 26 Jan 2021 10:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vR0fpB3c7b2E; Tue, 26 Jan 2021 10:40:49 -0800 (PST)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D84F53A0B5B; Tue, 26 Jan 2021 10:40:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=7086; q=dns/txt; s=VRSN; t=1611686449; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=z+JGlYUHND7ZOOl1+zRgCCkXCM3Q8dCaGipt1vhtw3E=; b=V9bw1XzKLkMFRZGlIJkwfSxUiBoJrNQUsLn3jhQUPVjLscPsJ2yXOGx4 T4Uw8xj10q1XU/gOZ8VDhn77ra14MosCeOOrwsAQEw6X2MkOXBj0tPdWL v2qjNc1GQQtXvum0ehFyr9C7ztPkSbPFML6uqIlJLaYhHPgywR3PJRvTd k67wwhj7E5HDXZBciN1XFntk3zcInYNRiK8wjxLm1OZojzVRVvOHuBg/a +7vG/V8hs4u+HJZkb5u6DJufDNES3I08/ZTspW2nPVKrcSwQcb3lKfPma tAq3oS4PVPyS4kIXUHiZt36Uvrj88nX0qChnFc+GbYNW6T1ru5FgnSNmo Q==;
IronPort-SDR: JFrVcZEyzS4ELxOGUejOVGHLKC7wEDiNuZdcpQwpW8nh5aHahw0QfV8q/EQoQ13PU8ztd0APL6 PWkqjKdiO334keKKDej52AL3O1YULrULJXp4p7utEG2siQCYwZkxPBrNexP1xMFBXhIVn07qKh 7vbQPmWPEpF2iEoBnt07foHw4mVvnPi2oNBjb+MzS0DiqRavFVvNEBlx0T1+KN4e8xkJA5cuKJ jnKVJEm57UiU4tJVE9c4lwiMNAoQJynfwpIyOlrw/D0Yjpjtgc2y3TGMSe2cWWBiZkDuFhGI8s qnE=
X-IronPort-AV: E=Sophos;i="5.79,377,1602561600"; d="scan'208";a="4873940"
IronPort-PHdr: 9a23:EjNLRRGdhSU8fwphjuDyLp1GYnF86YWxBRYc798ds5kLTJ76pcm6bnLW6fgltlLVR4KTs6sC17OH9fq+EjdYqdbZ6TZeKcMKD0dEwewt3CUYSPafDkP6KPO4JwcbJ+9lEGFfwnegLEJOE9z/bVCB6le77DoVBwmtfVEtfre9FYHdldm42P6v8JPPfQpImCC9YbRvJxmqsAndrMYbjZZmJ6or1BfEo3REdupKyWh1IV6fgwvw6t2/8ZJ+8Slcoe4t+9JFXa7nY6k2ULtUASg8PWso/sPrrx7DTQWO5nsYTGoblwdDDhbG4h/nQJr/qzP2ueVh1iaUO832Vq00Vi+576h3Uh/oiTwIOCA//WrKl8F/lqNboBampxxi347ZZZyeOfRicq/Be94RWGxMVdtTWSNcGIOxd4sBAfQcM+ZEoYfzpFUBrRqiCgejC+zi0SNIiWTz3aEmz+gsCwPL0Qo9FNwOqnTUq9D1Ob8cXe60y6nI0DHDYO5O1Tzg7IbHaBUhru+XXb5+bMHczksvFwzCjlWNrYzqIiiY1voTvGiB7upgTuOvi2Ehqw1rvjevwcIsh5DPi4kIxV/K6T93z5wpJd2kVkF7e9ikHYNMuiyeOIV7QMcvTmN0tSomyLAIt522cDYFxpkowxPRa/OJfoaK7x7/SuucPSt1iXZrdr6hmRu//0iuxvDiWse01ltBsyRLkt7Jtn8X1hzT7NCKSuVj8Ue72DaPzAHT6u5CIUA1k6rUN4QtzaI3lpoWt0nIAyz4mF3ugaOLakko4PWk5ubpb7n8u5ORN4F5hhvxP6kqgsCzHPg0PhITU2WZ5eiwzqDv8EL6TblQk/E7ka/Uu43AK8sBvK62GQpV354m6xa4EjipzswVnWICLFJZYBKHiJXpO03WLPD4E/i/h1OsnS92yv7aJrPtH5XCIGDMnrjgYbpx9VRQyBQvwtBY/ZJUEqsNL+juVUPrqtzYFAQ5Mwquz+n7D9V905sSWWOJAqCHLKPfqUKE6v41L+WRZoIYtizxJ+Ul6vPgl3M0llsQcbGs3ZQNaXC4GvpmI1+eYXrpmtoBE2gKvg0jTOzulVKPSiBTaGioX6I9/TE7CY2mDYHZSo+xh7yB2T+3HodKaWBeFlCMDXDoep2fVPgWciKSOM9gkjgaWrigUIAuzwqjuxP9y7piNurU5zEYuoz51NRv4O3Tjx4y/yRuD8uBy2GNU310nmQQSjArxqBwu0J9ykua3ah5nfNYCdJT6+pTUggkOp7T0eN7C8zrVgLceNeJSEypQtO7DjE1UN0+3sYCY0BnFNWnkB/DxDKqDKUJmLOVH5w46LjT33z1J8tmynbJyrUhj1c8TstIL22mibZ19xLPCI7Rj0WZi6GqeLwG3CHT+2eM02WPvF1DXQ5xT6rFQX4falHRrdTj6UORB4OpXP4tOxFb2MqPK6FDQtbuiE1bWPr5ftPEbCj5z225HwyZwr6NZoPCcGIYxDjBBVJClBocqzLOfwQkDym95mPTEDIrD1/gblPwtPR4qHq9Qks5w0SMZkhszKK88RMOw/WYT9sS064K/iA7pH88SFqn1tzKTtuNuwQkZqhTbMMhpUpB1WvfuwhwMtmmJqVvnUYXeAls+Urq0z12B5lO188woyV54hB1LPfS/1Rccz/clbL5P7DMYCGm/h+odqra8k/TyteN+6gJrv8/rgOw70mSCkM+/iA/gJFu2HyG68CSAQ==
X-IPAS-Result: A2H4BACOYRBg/zGZrQpfA4EJhHCBOQqENpEzJYQAllyBLDwLAQEBAQEBAQEBCAETDBAEAQEChEgZgWMmOBMCAwEBCwEBAQUBAQEBAQYDAQEBAoZODII4Ins9DT0BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAggHTQdHIAYjET4HEgEGAhoCJgIEMBUSBAENBYMmAZlMnAiBMopZgQ4qhnyEG4InQYFCPoERJwwQgWpsPoQACQESAQkvCiaCUjSCLASBVAEQWQZbCQRDDyMmPQwPKwcGBA0TBAIFCgMWCwMUJo87GYMlh2CdUAMHgneJMJJCH4MrgTCJBIVmjzOUHokgEoFtkgGENgIEAgQFAhaBbYELcHAVZQGCPglHFwINkhKKWHQOJgMCBgEJAQEDCYlRLYEGgREBAQ
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 26 Jan 2021 13:40:46 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.2106.006; Tue, 26 Jan 2021 13:40:46 -0500
From: "Gould, James" <jgould@verisign.com>
To: "barryleiba@computer.org" <barryleiba@computer.org>, "draft-ietf-regext-unhandled-namespaces.all@ietf.org" <draft-ietf-regext-unhandled-namespaces.all@ietf.org>
CC: "regext@ietf.org" <regext@ietf.org>
Thread-Topic: AD review of draft-ietf-regext-unhandled-namespaces-06
Thread-Index: AQHW9BLCaiOO3I8zckOqOOgrPeTHTA==
Date: Tue, 26 Jan 2021 18:40:46 +0000
Message-ID: <D1A18010-57B7-4A28-9836-67BAD4E8D3CC@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.41.20091302
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <28363193FF77D145B71D8F28F7A1EE56@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/wL9sGFZC6pmYFFpMDfgl-cdPTOg>
Subject: Re: [regext] AD review of draft-ietf-regext-unhandled-namespaces-06
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2021 18:40:51 -0000
Barry, I respond to your feedback embedded below. I saw Martin's reply that I reference for section 3 below. I will publish draft-ietf-regext-unhandled-namespaces-07 once these items are agreed to. Let me know if you agree with the proposed updates below or if you have any additional proposed changes. Thanks, -- JG James Gould Fellow Engineer jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 1/22/21, 2:23 PM, "Barry Leiba" <barryleiba@computer.org> wrote: Thanks for the publication request for this document; here's my AD review. None of this is a big thing, just some easy tweaks. It will need a revised I-D, though, so I'll set the substate accordingly. The Abstract goes into more detail than the Abstract needs to or should. The Introduction correctly explains the details, but the Abstract shouldn’t. I suggest trimming the Abstract thus (but please do use your judgment on this): NEW The Extensible Provisioning Protocol (EPP), as defined in RFC 5730, includes a method for the client and server to determine the objects to be managed during a session and the object extensions to be used during a session. The services are identified using namespace URIs, and an “unhandled namespace” is one that is associated with a service not supported by the client in question. This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs that is compliant with the negotiated services defined in RFC 5730. END JG - I took your proposal with one tweak in removing "in question" from "client in question". — Section 1.1 — Please use the new BCP 14 boilerplate and add a normative reference to RFC 8174. Indentation and white space in examples are provided only to illustrate element relationships and are not a REQUIRED feature of this protocol. That’s not a BCP 14 usage of “required”, and should be in lower case. JG - Done — Section 3 — XML processing of the <value> element is disabled in [RFC5730], Where and how is this stated in 5730? I can’t find anything, but perhaps I just don’t know where to look. It would be good to add a section number to the citation. JG - This is not stated in the text of RFC5730, but is based on the XML schema use of the processContents="skip" attribute of the "errValueType" type in section 4.1 "Base Schema". How about revising this to read "XML processing of the <value> element is disabled by the XML schema in [RFC5730]". Martin provided more context around the use of the <value> element, but I believe that we can provide clarity around the statement with the reference to the XML schema. Does adding this help clarify the statement? — Section 8.2 — Please change the Registrant Name to “IETF” (you may leave the email address as it is), as that’s how the IESG prefers to designate it (the IETF JG - Done — Section 10 — Nit: make it “This document does not provide…” JG - Done That aside, I would be surprised if we don’t get some pushback about this section, so maybe we should think about it a bit more. I accept that there are likely no security issues raised by this operational practice, but it would be good to address that more directly. This is proposing that a server return information to a client that indicates that the server believes a particular service is not supported by the client. You should call that out, and consider whether that could expose anything that could be used by an attacker — or that could be misused to create an attack. Or, could an attacker do something related to this practice that would allow it to disrupt some legitimate communication? The answer to all of that might be “no”, but it would be good to… as we used to say in school, show your work. JG - Yes, the quick answer is that I don't see the server using this as a source for an attack, but we can add a consideration to help mitigate it. I can add the sentence "Since the unhandled namespace context is XML that is not processed in the first pass by the XML parser, the client SHOULD consider validating the XML when the content is processed to protect against the inclusion of malicious content." The content is not processed by a client that doesn't support the service, where the <extValue> element provides a signal of the lack of client support along with the XML content that is initially unprocessed. If the client does decide to process the XML content systematically, the additional sentence can provide guidance to not open up a security hole. Do you believe this will help? Do you have any additional recommended text? -- Barry
- [regext] AD review of draft-ietf-regext-unhandled… Barry Leiba
- Re: [regext] AD review of draft-ietf-regext-unhan… Martin Casanova
- Re: [regext] AD review of draft-ietf-regext-unhan… Gould, James
- Re: [regext] AD review of draft-ietf-regext-unhan… Barry Leiba
- Re: [regext] AD review of draft-ietf-regext-unhan… Gould, James