Re: [secdir] Secdir review of draft-ietf-regext-10

"Linlin Zhou" <> Thu, 04 October 2018 03:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3F41C130DD8; Wed, 3 Oct 2018 20:05:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0neFKX3YX0ZD; Wed, 3 Oct 2018 20:05:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3FFA5130DD5; Wed, 3 Oct 2018 20:05:50 -0700 (PDT)
Received: by (Coremail) ; Thu, 4 Oct 2018 11:05:48 +0800 (GMT+08:00)
X-Originating-IP: []
Date: Thu, 4 Oct 2018 11:05:48 +0800 (GMT+08:00)
X-CM-HeaderCharset: UTF-8
From: "Linlin Zhou" <>
To: "Charlie Kaufman" <>
Cc: "" <>, "" <>, "" <>
X-Priority: 3
X-Mailer: Coremail Webmail Server Version XT3.0.8 dev build 20171117(fcd8b4ed) Copyright (c) 2002-2018 cnnic
In-Reply-To: <>
References: <>
X-SendMailWithSms: false
Content-Type: multipart/alternative; boundary="----=_Part_17539_32766054.1538622348351"
MIME-Version: 1.0
Message-ID: <>
X-Coremail-Locale: zh_CN
X-CM-SenderInfo: p2kr3zplqox0w6fq0xffof0/1tbiAQAIBiVCN4lulgAAsu
X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU=
Archived-At: <>
Subject: Re: [secdir] Secdir review of draft-ietf-regext-10
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Oct 2018 03:05:56 -0000

Hi Charlie,

Thanks for your review.

Maybe I can give some arcane explanations for these words.

According to RFC5730, EPP can use authentication information associated with objects to confirm object-transfer authority. With an <obj:authInfo> element, the server operators can confirm the authorized or unauthorized requests.

The original design of this draft has <org:authInfo> that is associated with org object to facilitate transfer operations. After some discussions, this element was removed for some reason in the XML schema and element descriptions. Given that the element was removed, it is indeed inappropriate to have these words here to make readers confused. It is our neglect. So we suggest deleting these words.




发件人:"Charlie Kaufman" <>
发送时间:2018-10-03 12:01:25 (星期三)
收件人: "" <>rg>, "" <>rg>, "" <>
主题: Secdir review of draft-ietf-regext-10

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This specification defines a syntax for extending the Extensible Provisioning Protocol (EPP) [RFC 5730] to support a new object type representing organizations. It does not change any aspect of the security of the protocol, and I believe it therefore does not require any sort of detailed security review.

There was one line that I found curious. It might be a typo, or there might be some arcane explanation:

The last paragraph of section 4.2 reads:

"Server operators SHOULD confirm that a client is authorized to perform a transform command on a given object. Any attempt to transform an object by an unauthorized client MUST be rejected, and the server MUST return a 2201 response code to the client to note that the client lacks privileges to execute the requested command."

Given that unauthorized requests MUST be rejected, it seems curious that server operators only SHOULD confirm that the requestor is authorized. I don't know how else the server operator could know to reject unauthorized requests. Perhaps this relates to the question of whether a queued request is rejected before it is queued or only as it is eventually processed.

But this is truly a nit, and even if wrong I don't believe it would ever cause an implementation to be incorrect.