IETF Logo Mail Archive

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

Patrick Mevzek <pm@dotandco.com> Thu, 31 March 2022 15:55 UTC

Return-Path: <pm@dotandco.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 D7BC43A02BC for <regext@ietfa.amsl.com>; Thu, 31 Mar 2022 08:55:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.11
X-Spam-Level:
X-Spam-Status: No, score=-7.11 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_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=dotandco.com header.b=fBEuXmpT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ju3mOdnO
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 n33wJ6mHL28x for <regext@ietfa.amsl.com>; Thu, 31 Mar 2022 08:55:50 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB86D3A0033 for <regext@ietf.org>; Thu, 31 Mar 2022 08:55:50 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 48E7632020F4 for <regext@ietf.org>; Thu, 31 Mar 2022 11:55:46 -0400 (EDT)
Received: from imap45 ([10.202.2.95]) by compute4.internal (MEProxy); Thu, 31 Mar 2022 11:55:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.com; h= cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm3; bh=VM/L4v9LUhBT+HdPdDRPl5yNCPmvMbMdhwd6Ng WHFNc=; b=fBEuXmpTmkrlG148FHolhqXNgpvR9FrYWQiUQ7ytF1QKZsE8wK8Wee 3KNAdvD7iS5C9tZVCUJjvYPq6eV54LcpswpshoUsf5yc6f7xSef1xiRoU5sPXuyz GSIKLmWWDxpei0BrsqioeG4p/JdcSb4H8Abigw+3nuoGiuaH1cODiQZcjriTYr2S hIFrtxkr6Hi/GzfqJ3FCttq0dr7ZOnSZ4Ixlu/Wb4QaqJPsesJ6McmPw9JGIR7HS v2kB1GCgLK4GWJ5m+cJCk4pB6QKxLcwmNn5FrOtDfyEtKXXVDATYYX+pMIMjRuW6 69Lp4FOPz+7u7eKjbCItZkvTw+Ijx+xg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=VM/L4v9LUhBT+HdPd DRPl5yNCPmvMbMdhwd6NgWHFNc=; b=ju3mOdnOQm6pRozFtMXLL5bPfb5CbCVK7 KL60Msjg715Fiowi5w0BJ/VYUdeZp/yFuR0BJoxaVhta8p7phq+BUXhnULNoirFF lSsM8v47erxPKj+ic0y32FOveWgVOt01YD6MdK6JaOlTX9I7EF+5FbtKcBJtQ+yY EaaKhlXAFgdOTdiRwskvGU5CbPDhaBO7FuYerDEnt0gdjebDU+dhgn0rlLR7o6VP C8t8Yb2NAY+4iahVLQKOKjPtCvnauPV94/6jXbvDAIWnaItWxUUCeg88xYW6hYsB DtCWoBjUB2nmfwEuH0X4gJuZC81cQBaU5RtCGZXc0ILXS+paOcCag==
X-ME-Sender: <xms:Ac9FYmBFnf_Xf6HmhxU5XVRK8ChLGIqlYm-K6FdkWq57SL9A-lFqWN-6peo> <xme:Ac9FYgjmwJ4aqhD9V82pQYeyKWbxdXMDeSoRH78StiQMYPC3INfiwREDYygMiBkDC WQgpzI5cjptkVHJ5A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudeigedgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfrfgrthhrihgtkhcuofgvvhiivghkfdcuoehpmhesugho thgrnhgutghordgtohhmqeenucggtffrrghtthgvrhhnpedvgeeuhfeffeefkeelveehfe ekvdffheehkeehvdehtdfgjedvueejhfegvdeuhfenucffohhmrghinhephhhtthhpshgv shhsihhonhifhhgvnhhrvggtvghivhhinhhgrghnvghpphgtohhmmhgrnhguohhthhgvrh hthhgrnhhthhgvlhhoghhinhgtohhmmhgrnhguihhsihhnrdhithenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpmhesughothgrnhgutghord gtohhm
X-ME-Proxy: <xmx:Ac9FYpl5jd2grNlFEsGCgiXsxBa-Q5iDjr0O1ngS_S33Yz-zTAnogg> <xmx:Ac9FYkyoa3z73nu3ZCYFApFyFqq4np4Oosl-prsx4lSb0WzAhNMgWQ> <xmx:Ac9FYrS0Xv3Nr9WZ_Jb1VjL6OwiM8wJfBYvoor-_joqXZ3P3SUKJCg> <xmx:Ac9FYif8jNTP9bP-TZiCYojeJwG4Xrg5XIO1SoTEAtESXikBeDtwxQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 77ACC24A049A; Thu, 31 Mar 2022 11:55:45 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-382-g88b93171a9-fm-20220330.001-g88b93171
Mime-Version: 1.0
Message-Id: <58f622e5-1548-4894-a14c-c21125972a74@www.fastmail.com>
In-Reply-To: <759658bd-4781-a9cb-b7dd-88ba596fe2b0@iit.cnr.it>
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>
Date: Thu, 31 Mar 2022 10:54:19 -0500
From: "Patrick Mevzek" <pm@dotandco.com>
To: regext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/85BvzaHqEG1JUTt5vZUYKgwlETk>
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 15:55:56 -0000

On Thu, Mar 31, 2022, at 10: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.

I disagree.

If the transport is HTTPS (and not just HTTP), the server can request
the client to send a certificate, exactly as for EPP over TLS.

In such case, for *any* HTTP request coming to the server, the server
theoretically already knows to which client this pertains as it can
consult the certificate given.

It can be considered a weak or partial authentication, until the EPP login
is successfully executed.

-- 
  Patrick Mevzek
  pm@dotandco.com

v2.8.7 | Report a Bug | By Email