Re: [regext] How to handle Domain Info Command with empty authinfo/pw tag in command?

"Gould, James" <jgould@verisign.com> Fri, 20 December 2019 16:47 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 EEF59120856 for <regext@ietfa.amsl.com>; Fri, 20 Dec 2019 08:47:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 fZSJLdgsLkLv for <regext@ietfa.amsl.com>; Fri, 20 Dec 2019 08:47:42 -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 ED8C212084D for <regext@ietf.org>; Fri, 20 Dec 2019 08:47:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=15407; q=dns/txt; s=VRSN; t=1576860462; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=8RQxUFrKr/d9GJVvYS8uqCetFLy7cuxrCAglEoXfmEE=; b=Oex1Wd+8q0iQj0/bVL6hNBTA09ra2YPUwVMdLwvyPyWPi+y+8f55CyQ1 7leTELSZHXw3uozmqOzMQ54v143e5AdjylVfzL477V//t3IyEBxyXLHXq LXDU5wOdQEhLRhl5m4B/253uNlGanQjoeWBvjUc9/OgUEn3xDVNP4pNFg mV9JoaPi61ljyWqRBsUcwlPf5wezdr/d0tMw+Zm+iA3PLzvdv/rf3O3n5 LT430t8iU0QGkLHh3iyahGKhUxWXFkqQ1ujJ8rC8pJ2XDhhX8ip9bwhzq w7HVAhf/dnfdaFQ3ud7ZXNy3+SUo30llrMcVqLpVctaU+uBXjyazKKYVQ Q==;
IronPort-SDR: 2bGMgBn2nxv2UCtvjLmiCIO96ZyuPUexq9H+wYTAmNUnkjZ193dTcKDdxrhBNw+gGpR70xLwi+ dlEDo4ETtlgx20mUT+urip7Ok2qcW5OgDYCNK3QZVDE9R7g9LQLSM+V/TVjz2KLvBKceJXps3e PxvBuwwi6Sbooe7hZm783W10rMv/G6+BeCftKCaAwmWH7ClK54ObndpIh+cGCOnJyryOs+ON5/ mTcCipsPLQbnv6cZi6oGGFYt5W+gJivuiSo9HkXzMhlVwmxAd/HYCQFiYbRqeyRRgQbOhW8bzC y/8=
X-IronPort-AV: E=Sophos;i="5.69,336,1571716800"; d="scan'208,217";a="301224"
IronPort-PHdr: 9a23:oxrjNhSHdd85j+ApUngeqYiIVtpsv+yvbD5Q0YIujvd0So/mwa67ZBeAt8tkgFKBZ4jH8fUM07OQ7/m7HzZZut3R4TgrS99lb1c9k8IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUhrwOhBoKevrB4Xck9q41/yo+53Ufg5EmCexbal9IRmrowjdrNcajZZsJ6o+yRbEpmZDdvhLy29vOV+dhQv36N2q/J5k/SRQuvYh+NBFXK7nYak2TqFWASo/PWwt68LlqRfMTQ2U5nsBSWoWiQZHAxLE7B7hQJj8tDbxu/dn1ymbOc32Sq00WSin4qx2RhLklDsLOjgk+2zMlMd+kLxUrw6gpxxnwo7bfoeVNOZlfqjAed8WXHdNUtpNWyBEBI63cokBAPcbPetAr4fzuUYArQewCwevCuPgyDFHhn7q0qI1yOkuCx3K3Ak6Et4SqnnZrtP4P7oSX+Cvy6nIyC3OY/1X1zf69YjIdg0uremRVrx0a8XRzFcgFxjLgl6NroHlPTyV1uMQs2if8uVtTvyvhHA9qwFwuTivx8gsio/Tio0JzVDE8Dx0zYAoLtO2T057ZMSrEJpWtyyCKYt5XNkiQ2BzuCY7xb0Gv5+7fC4Wx5g92xHfbPmHf5CS4h39TumROjB4hHR/dLKniRe+6UmgxfPgVsm6ylpKqTBFktbKu3sQ1BLT8tCKRuZh8ku7xDqC1Q7e5vtZLU00m6fXMZEsz70ompYOrUjPBDL6lUfqgKOMa0kp9eul5/76brjlvpOcOZF7hwLiPqkrn8GwG+c1PwwVUGWe9+mwyqDs8Ez8TbpRivA7k6vUvZXUKMkVpKO2HglY2Zs55RmlFTepytEYkGECLFJCZR2IkZDkO0rLIPDkFfe/hEmskCtzy/DGILLhBpLNI2Denbn9Zbhx9k5TxhI8w99e+55YF6sNIOzvVU/2rtzYFgU1PBapzOr9FtV9zJgeWWSVDqCFN6PStEeE5uMpI+aSeI8YoCvxJ+Q/6/Lzj3I0l0URcbSp0JYZcny1EfdrL12cYXX2g9cBFWkKvhA5TOzvkFCCUzFTZ3GvX6I4+z42E5ymApnZRoCsm7yB3Si7HptMam9aDVCMFG/kd5+YVPcUdCKSPshhnyQcVbikUIIuyBautBPgxLphM+Xb5ioYuYj/29hy4u3ZjQsy+iBsD8SBz2GNSHl5nnkWSD85wq9+rlB9x0yC0admn/xYG8Zf5/RTUgc1ZtbgyLlCAszoWwnCNvKEVkSrQZ3yGTQZQtUtytkCaEE7ENKn2FSLlTCnDLIFi5SKCYA6tKXG0DK5c9xwxHvWyIEggkUoBMxVOjv1qLR48l2ZKInUl0nd34SjcKkHlmaZ9miE0G6ClF9VSg9rUKrDG3sYYx2F/pzC+kreQur2WvwcOQxbxJvHc/MSZw==
X-IPAS-Result: A2GaAADR+vxd/zCZrQpiAx0BAQEJAREFBQGBagYBCwGBHVOBHYExCoN9jlmCQ4NtlUmBPxcdCAkBAQEBAQEBAQEHARgBCgwBAQKDeUUCF4IqNgcOAgMBAQsBAQEEAQEBAQEFAwEBAQKGIAyCOykBaS8JATgBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAggHNBkHNRIBAR4BAQECAQEBIQpBEAsCAQgOIgsHAgICJQslAgQBCQmDIgGBeV4vq3CBMopYgTYBjDKBQj6BEScggh4uPoJkAQGBegomCIJBMoIsBI0/gnWFV4lhji10AweCNIcyjwGDOpcbjlGHR2MokgICBAIEBQIVgVkEggdwFTsqAYJBCUcYDY0eFxWDO4UUhT90DSSRFIENgRABAQ
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Fri, 20 Dec 2019 11:47:37 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1779.002; Fri, 20 Dec 2019 11:47:37 -0500
From: "Gould, James" <jgould@verisign.com>
To: Patrick Mevzek <pm@dotandco.com>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] How to handle Domain Info Command with empty authinfo/pw tag in command?
Thread-Index: AQHVtxKgh4v25DmWhkKBFzlwUC/VbafDDxgAgAAtIgA=
Date: Fri, 20 Dec 2019 16:47:36 +0000
Message-ID: <436A323C-AD02-4FFE-A182-B9376AFF3783@verisign.com>
References: <d17d88d0-e9db-9416-1917-dc992fcd2d3a@switch.ch> <35BAECA0-9B4A-4C1F-9EEF-BA9C4BE2E325@verisign.com> <4bbb8a33bee54a8797fc75a1cf532899@switch.ch> <185b57cd-984c-4167-8e62-fc37dcf46fdf@www.fastmail.com>
In-Reply-To: <185b57cd-984c-4167-8e62-fc37dcf46fdf@www.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.f.191014
x-originating-ip: [10.170.148.18]
Content-Type: multipart/alternative; boundary="_000_436A323CAD024FFEA182B9376AFF3783verisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/-10zIz7rTMdVTPurbGHIS0iWE0k>
Subject: Re: [regext] How to handle Domain Info Command with empty authinfo/pw tag in command?
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: Fri, 20 Dec 2019 16:47:46 -0000

Patrick,



The EPP RFC 5731 does support the explicit <domain:null> element to remove the authorization information, so there is an explicit mechanism available in the RFC to set the authorization information to NULL (the undefined value).  For example, the following can be used to delete the authorization information:



...

   C:        <domain:chg>

   C:          <domain:authInfo>

   C:            <domain:null/>

   C:          </domain:authInfo>

   C:        </domain:chg>

...



Where there is no explicit element in the EPP RFCs to indicate not setting or unsetting the authorization information, the empty authorization information can be used for this purpose in a defined practice, such as draft-gould-regext-secure-authinfo-transfer.  We need to ensure that the empty authorization information never matches the unset authorization information to protect the authorization of actions such as returning the full info response or executing a transfer request.



Having discussion and agreement around the authorization information practice would help with the inconsistencies that you outlined in your follow-on message, and help increase the authorization information security.



--



JG







James Gould

Distinguished 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 12/20/19, 4:06 AM, "regext on behalf of Patrick Mevzek" <regext-bounces@ietf.org on behalf of pm@dotandco.com> wrote:







    On Fri, Dec 20, 2019, at 03:50, Martin Casanova wrote:

    > I agree that hashing an empty String to match a not set authinfo is not

    > the way to go. We are using [null] values in the db for a not set

    > authinfo field. However I think you could argue that semantically and

    > empty XML tag is somewhat similar to a not filled db field being [null]



    I strongly disagree.

    It is the same thing as the difference in an RDBMS when you store "" (the empty string)

    or NULL (the undefined value). Those are two different things, and for good reason.



    <pw/> or <pw></pw> means an empty password, the empty string.

    No XML pw node means an undefined password, as the data is just not there, so unknown.



    Like said in other threads, this all shows to me that efforts should be put

    into finding now new ways to operate, without domain passwords as they became

    useless, instead of trying to fix with various warts the current situation.



    --

      Patrick Mevzek

      pm@dotandco.com



    _______________________________________________

    regext mailing list

    regext@ietf.org

    https://www.ietf.org/mailman/listinfo/regext