Re: [regext] Secdir last call review of draft-ietf-regext-epp-eai-12

"Gould, James" <jgould@verisign.com> Wed, 17 August 2022 13:02 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 AB122C1522B4; Wed, 17 Aug 2022 06:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TaGYznFrzh4j; Wed, 17 Aug 2022 06:02:00 -0700 (PDT)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (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 D1A9EC1522B2; Wed, 17 Aug 2022 06:01:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=7752; q=dns/txt; s=VRSN; t=1660741320; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Nn6skK4eX7FlotKGMTynRLatgB0jJE7tJi0ElxrF+lI=; b=pDaXx8rz5sVuPKFd3gjKi5Wd3LIDuWMIvH5BC7tK0BtRLDkF74rFX1qk benRlnEDGvmmC+ALtGmse9FQrh9CGVI/tYp0tyEhuPUcbQo3IdDCyJi20 lhnEtl1ofE9N0QkPwfxHqgoOGI87bsh7qWpnerk6fBVO0EjQVtHsrI8Ya tsg93A1T5vRfZlJieOKyCF1ckxKh0swEo+MED4dVcmKNe1KetvUMRJH95 6cBZy0ABLKYy2jWcVh7ks/D3eRFfDrP6acnEgmXy6YSABLgM0HGXqC0Bs uqG11T5Sry6PNu0x79zEZrFnhhcZpWpSVzV2grB2HZ/1vuYvSLm8gbEAk g==;
IronPort-Data: A9a23:Y/nkqqm1LXjjNKMvvJyFYgfo5gyUJ0RdPkR7XQ2eYbSJt1+Wr1Gzt xJOUGzSbKqPYjenKo0kPYm/pE4D75GGxoViHQNq+SwzEy4T+ZvOCOrCIxarNUt+DCFhoGFPt JxCN4aafKjYaleG+39B55C49SEUOZllwtMQMcacUsxLbVYMpBwJ1FQywIbVvqYy2YLjW1PU5 ouryyHiEATNNwBcYzp8B52r9UsHUMTa4Fv0aXRnOJinFHeH/5UkJMp3yZOZdhMUcaENdgKOf Nsv+Znilo/v10x0Vo76yOaTnnoiGdY+NSDW4pZfc/b63kga/kTe2I5jXBYXQR8/ZzlkA7mdY TiC3HC9YV5BA0HCpAgSezxfEj8hFIhUwZjgHX6mrt2RwXHfU1K5lp2CDGluVWEZ0sxNJzhx0 9EocGpLcBuEnfrwyb79VPN3gIIoK8yD0IE34ykmlG6CS697GtafEs0m5vcBtNs0rsJBGuvaa +IHZCBudxXPZVtEPVJ/5JcWxbfy2CCnK2cwRFS9o4Rvx0zy8QtL9KXqNdfua9aGYZUOtxPNz o7B1yGjav0AD/Sbzjyb83mvwO7CgS3TV4cbFbn+/flv6HWIy2cfCQc+VFanr7++kEHWc95FI kIIvysjsaZ37kGkQ8nhGhCguDuJtx9aUt5UO+w39A/LzbDbiy6dD3MYCzVIbNgOtcIqS3otz FDht8nkCjF/rJWURG6TsLCOoluP1TM9J3UEPDACQBtduZz4vpt1ixPUC9xkVqSviISzByvrx XaBqy1Wa6gvsPPnHp6TpTjv6w9AbLCQJuLpzm07hl6Y0z4=
IronPort-HdrOrdr: A9a23:gCwCGqGPN8S90rcCpLqENceALOsnbusQ8zAXPidKOHlom62j5q KTdZsgtSMc5Ax+ZJhCo7+90cC7KBvhHPVOkOos1NmZPTXOiS+HIIZv9oP+zzClMD2WzIJg/J YlV6RlEtX/ARxZgdaS2mOFOudl5NWc6qiniaPl0nF3QWhRBp1I9QtjFQqBKEFwSTRHAZZRLv Gh2vY=
X-IronPort-AV: E=Sophos;i="5.93,243,1654560000"; d="scan'208";a="18261002"
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_256_GCM_SHA384) id 15.1.2375.31; Wed, 17 Aug 2022 09:01:48 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) by BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) with mapi id 15.01.2375.031; Wed, 17 Aug 2022 09:01:48 -0400
From: "Gould, James" <jgould@verisign.com>
To: "lonvick.ietf@gmail.com" <lonvick.ietf@gmail.com>, "secdir@ietf.org" <secdir@ietf.org>
CC: "draft-ietf-regext-epp-eai.all@ietf.org" <draft-ietf-regext-epp-eai.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: Re: Re: Secdir last call review of draft-ietf-regext-epp-eai-12
Thread-Index: AQHYsjmC2XTusqEhh0+u0SYlhTuEDQ==
Date: Wed, 17 Aug 2022 13:01:48 +0000
Message-ID: <62FBCB8F-6934-442D-871F-E7EDE928D4ED@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.62.22061100
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <1EBEDF29A41227469E8C4A6EE31B4D28@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/qgEophth-YzyeeZiC-rT6GQNTaM>
Subject: Re: [regext] Secdir last call review of draft-ietf-regext-epp-eai-12
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 17 Aug 2022 13:02:04 -0000

Chris,

I'm following up on my prior message.  If the revised language included in the prior message addresses your feedback, can you clear the SECDIR "Has Issues" status? 

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 7/26/22, 12:59 PM, "Gould, James" <jgould@verisign.com> wrote:

    Chris,

    Based on the feedback that you provided, we did add the proposed language below to the security considerations section of draft-ietf-regext-epp-eai-13:

    When the EAI functional extension is negotiated by both the client and the server, the client and server obligations defined in Section 5.3.1 MUST be satisfied.  If the obligations are not satisfied by either the client or server, the EAI address may be mishandled in processing or storage and be unusable.

    If this addresses your feedback, can you clear the SECDIR "Has Issues" status, or let us know what else needs to be addressed?

    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://secure-web.cisco.com/1OQPesap4SNktE_yB9zHO6DcAcbco8H43992haWb2YQarKfNV6ejOiyLWkQnaFsLXOnj7u0dF7mcO2OLOjUvm-iheDDzxTKvHsyLiEFvbLdFVXIS2DUI7OwIrGVIUhZhUXcqRy_yusuzP1hklyHXl3Wtiu-KhyITIGN2RvBE3BmnYg0Dce-MhXOlR3d6aRHihNoGgLa_4CnwYbykJxU5hNRGM3tdGD6R-UFG9YTu8mYmB_JHYIOY30Ha5Cg9apEwb/http%3A%2F%2Fverisigninc.com%2F>

    On 6/13/22, 11:35 AM, "Gould, James" <jgould@verisign.com> wrote:

        Chris,

        Thank you for the review, feedback, and recommended text.  You mention an interesting use case of a client or server that signals the support EAI, but that can't meet the obligations defined in section 5.3.1 "EAI Functional Extension Negotiated".  The negotiation is handled when the EPP session is established via the list of services provided by the server in the greeting and the client in the login command.  In EPP there is no functional capability to not accept the service URI at the time of EPP session establishment based on determining compliance with a service / extension obligation.  For EAI, the negotiated services will imply the normative language in section 5.3.2 "EAI Functional Extension Negotiated" for the server and the client, respectively.  We could add the following to the security considerations section to cover the risk of negotiating EAI support without fully complying with the obligations defined in section 5.3.1:

        When the EAI functional extension is negotiated by both the client and the server, the client and server obligations defined in Section 5.3.1 MUST be satisfied.  If the obligations are not satisfied by either the client or server, the EAI address may be mishandled in processing or storage and be unusable.   

        Any thoughts on the language is appreciated.

        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://secure-web.cisco.com/175AUUsbJVaoxOezz1lqoGtSJG2fku7o0Lg9ShgFtnC4wowW2VYMrmIqsxvdw93PUXc2zhu3Qf0z8or4QFqBqV1mTbQMn9lQnbIOAVMsXaB1uY4hTJABd3GehICkvskowKXshb5UzeTUstLXIGspyEsa0X6-Tx3uhSauMW2UVMuMhcZSFxqATxnzJeBBNJ7EXOc99PT8z9_eFVgLD81xEbKtqiBqwX6PeIRQUx8qZCVCNK9JzfpLNjQjii2fyx5TI/http%3A%2F%2Fverisigninc.com%2F>

        On 6/12/22, 8:48 PM, "Chris Lonvick via Datatracker" <noreply@ietf.org> wrote:


            Reviewer: Chris Lonvick
            Review result: Has Issues

            Hello,

            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.

            The summary of the review is that it has issues.

            The document is well written and the Security Considerations seems appropriate.
            However, there is insufficient guidance given regarding when the EAI functional
            extension is negotiated, but when the server cannot satisfy the required
            obligations. The specification says that when the client and server negotiate
            the EAI functional specification that, "implies the possibility to process the
            EAI address". The draft needs to specify what happens if the client and server
            negotiate the EAI functional extension, but when the server cannot fulfill its
            obligations to provide the required information, or when the client cannot
            process the received information.

            This may be easily fixed by saying in the specification that the server will
            only accept the negotiation if it can (MUST) provide the required information
            specified in section 5.3.1 and that the client can (MUST) accept and act upon
            that received information. The specification should also go on to say what MUST
            happen if those conditions are not met.

            Best regards,
            Chris