IETF Logo Mail Archive

Re: [regext] Comments to the feedback about epp-over-http

"Hollenbeck, Scott" <shollenbeck@verisign.com> Thu, 31 March 2022 17:58 UTC

Return-Path: <shollenbeck@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 CC3CB3A1660 for <regext@ietfa.amsl.com>; Thu, 31 Mar 2022 10:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.109
X-Spam-Level:
X-Spam-Status: No, score=-7.109 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_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 3sInLQYHdYIm for <regext@ietfa.amsl.com>; Thu, 31 Mar 2022 10:58:34 -0700 (PDT)
Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.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 2D6433A1216 for <regext@ietf.org>; Thu, 31 Mar 2022 10:58:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2062; q=dns/txt; s=VRSN; t=1648749503; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=loPS3/6jKnfZ9bCGIOFcXQAL49JWXqxzCwGfOMwqwq4=; b=DJ1sVwc4EmSx7R0Zkc6PVry5GgLAjsk287a8kjTeM3dQTjpv3cuQdbW1 svogcweAc2gnBFnMqMhb/UEr4mINq4egJFB6EPlhW4hvDHuzxMalrRi2h GcwQywKpUTqX3lwCpow2xurTDh+gjMq/x1DzKeB05JFxpxENgJc6U4eZc qBiNKzymdZm52kkxmFqIex97tk+CfHXV9ty7ar1M1YFH/Kznx1kWldtHA RUBUkEuVF6g/Q5meRKOnV6sgXT4co61rJJ4CWcvy7TWgcWRebeZk/t5fz 1tRG6LVXnkP87ru/cgJIOssUGZHiJaP+FTg8oIxveEa5ZIFqbYcNpHzeZ w==;
IronPort-Data: A9a23:KCZDRqhPbtjNfJqviF6n9NmpX1613BIKZh0ujC45NGQN5FlHY01je htvCmnTOauJZGr2etAib4i0oEMD6p/Vx4RgSgBp/yE3FCoW8JqUDtmndUqhZCn6wu8v7K5EA 2TyTvGacajYm1eF/k/F3oAMKRCQ7InQLlbGILes1htZGEk1EE/NtTo5w7Rj2tUz2IDja++wk YiaT/P3aQfNNwFcbzp8B5Kr8HuDa9yr5Vv0FnRnDRx6lAe2e0s9VfrzFonoR5fMebS4K8bhL wr1IBFVyUuCl/slIovNfr/TLBVWEuaKVeSEoiI+t6OK2nCuqsGuu0qS2TV1hUp/0l20c95NJ NplmYXobDUsYJzwpc8gYkIHFz5MOoAYweqSSZS/mZT7I0zuWUHKmspIIXFuZMsG8eFtGSdH+ boGMisLKBuEgopawpriEq812Z9ldZSwet9P0p1j5Wix4fIOWpDER6HH49VV1zQYmM1UHO3fa MxfYj1qBPjFS0QTYgtHVcJh9AuurkbFSjhikQmynpht+UmU1CJzgYTOPfOAL7RmQu0QxC50v Fnuw2T+BxgBcveY0yaI2nGqh/fX2y/2MKoIGbK15uJCgVCPyCoUEhJ+aLegifOjjBehXd9Pc xVR4TQ0660z7wmhSZ/3RRvh5mCepRhaUN1VewEn1DywJmPvy17xLgA5ovRpMbTKaOdeqeQW6 2K0
IronPort-HdrOrdr: A9a23:oG9XMas1hr6AV4PM3hYmbR/P7skDXdV00zEX/kB9WHVpm5Sj5q WTdYcgpHvJYVEqKQodcLG7SdG9qBznlKKdjbN6AV7mZniFhILKFvAZ0WKB+V3d8kTFn4Y36U 4jSdkcNDSaNzRHZLPBjjVQZOxO/DDoys2VbKzlvhBQpElRGsddBilCe3+mLnE=
X-IronPort-AV: E=Sophos;i="5.90,225,1643673600"; d="scan'208";a="14048587"
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.24; Thu, 31 Mar 2022 13:58:21 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) by BRN1WNEX02.vcorp.ad.vrsn.com ([10.173.153.49]) with mapi id 15.01.2375.024; Thu, 31 Mar 2022 13:58:20 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "Thomas.Corte@knipp.de" <Thomas.Corte@knipp.de>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] Comments to the feedback about epp-over-http
Thread-Index: AQHYRPYWlKlXjhloxEaCk5yYnLJ6tqzZsQsAgAAyKQCAABxQAP//x40g
Date: Thu, 31 Mar 2022 17:58:20 +0000
Message-ID: <064b17f1fa5141089a8494edd8791663@verisign.com>
References: <0843A6FD-79B8-45B9-BE58-0BCED21C19B0@verisign.com> <1b87995b-700b-0d16-1241-c69cf142c3f7@iit.cnr.it> <8346151e-acc1-8e9a-f8ce-ac4d2f6a8dac@knipp.de> <759658bd-4781-a9cb-b7dd-88ba596fe2b0@iit.cnr.it> <460e37b5-3d0c-7139-8c5f-1f87c36c3177@knipp.de>
In-Reply-To: <460e37b5-3d0c-7139-8c5f-1f87c36c3177@knipp.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/wKji5ewKIwCF6AXVgkCUoyfS-4Y>
Subject: Re: [regext] Comments to the feedback about epp-over-http
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: Thu, 31 Mar 2022 17:58:39 -0000

> -----Original Message-----
> From: regext <regext-bounces@ietf.org> On Behalf Of Thomas Corte
> (TANGO support)
> Sent: Thursday, March 31, 2022 1:17 PM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] Comments to the feedback about epp-
> over-http
> 
> Caution: This email originated from outside the organization. Do not click links
> or open attachments unless you recognize the sender and know the content
> is safe.
> 
> Hello Mario,
> 
> On 3/31/22 17:36, Mario Loffredo wrote:
> 
> > Starting an HTTP session when receiving an EPP command other than the
> > Login command is in .it experience (but I can speak on behalf of .pl
> > too) very inefficient because you can't immediately lock the HTTP
> > session to the Registrar.
> 
> Ok, but plain TCP implementations have the same problem. Unless the
> registry requires that no two registrars have the same IP address whitelisted,
> the server always has to wait for the <login> until it knows which registrar has
> connected. That is, unless client certificates are also in play, as suggested by
> Patrick, but that's not a requirement in EPP, even if many registries are now
> requiring them.

[SAH] Client certificates ARE required for TCP transport with TLS. See here:

https://datatracker.ietf.org/doc/html/rfc5734#section-9

They're not specifically a requirement for EPP, but they are for that particular transport protocol (which just happens to be the only standard transport protocol).

Scott

v2.8.7 | Report a Bug | By Email