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

"Gould, James" <jgould@verisign.com> Fri, 20 December 2019 14:50 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 A47D5120072 for <regext@ietfa.amsl.com>; Fri, 20 Dec 2019 06:50:39 -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 vs6_wPlgh4ZX for <regext@ietfa.amsl.com>; Fri, 20 Dec 2019 06:50:36 -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 7177B12006E for <regext@ietf.org>; Fri, 20 Dec 2019 06:50:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=35718; q=dns/txt; s=VRSN; t=1576853437; h=from:to:date:message-id:mime-version:subject; bh=MznC7kQkKyHtsYJrM2iXuAYMZL1X7A9WX/CoKUmvqLA=; b=KpF70StjfXuLR/8kWPSDmvrpo6YXn6bgjCvgbw3SXyAT28moLcid97Fw IFo6cJHSC7q/RVOB5HXONuU1qn2m2DgZezID7MJvs/XV75bBqrTwoOoCi 3trXElXhOsi7ZQsrubLweGu9N57hG0BKWlva6rkZNfj1P+beS1P5fpiBd Ef9AwxbZyhwjZtojzVbM2Uk/bgngqgzJU8B8vZVbN/TZq2SfcpVj0Y0eA rBn6G8zb9ia2GmHeCMtQc2yQgluAfnaPYl40r+WpCBgpMhCo37dymyvJc 7stI/R9Y0y4shihBKEepTj45oq0LO9cwmit/2kK9DMgHJNStNKX+59apk Q==;
IronPort-SDR: 7O2W4cMn+w+urYuRlCGJHU4D6nrTZshYtMYH1OhtHj1H5cYoIT4rvZc4lke6luX9Kv3JYj7wfP OaPnoVT52g/u6P+akadrMG8aru+aggMth5tdCiuHB1ecJPs3ck7ndhL5Dgbz/mmbysL5vwa1lt LNs8TptPXVH9O/NruzglJOOLQOOzoMMI6XTqE8zPw1Aw86iP1hU68lTaW0JWUtlyC24bqOP21d BnTCdg+Mi+hbdN3HZOQK8w4KJ0PK+DXi/UKFlz33wOq1Mkva1IH7hAci3FqmgMdk05/U22pG+M 0IU=
X-IronPort-AV: E=Sophos;i="5.69,336,1571716800"; d="png'150?scan'150,208,217,150";a="300471"
IronPort-PHdr: =?us-ascii?q?9a23=3AJnTL/xwiCy3Pi1TXCy+O+j09IxM/srCxBDY+r6?= =?us-ascii?q?Qd0uoQLvad9pjvdHbS+e9qxAeQG9mCsLQe0rGd7f6ocFdDyK7JiGoFfp1IWk?= =?us-ascii?q?1NouQttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBXdrXKo8DEdBA?= =?us-ascii?q?j0OxZrKeTpAI7SiNm82/yv95HJbAhEmTSwbalsIBmrowjducgbjIp/Iast1x?= =?us-ascii?q?XFpWdFdf5Lzm1yP1KTmBj85sa0/JF99ilbpuws+c1dX6jkZqo0VbNXAigoPG?= =?us-ascii?q?Az/83rqALMTRCT6XsGU2UZiQRHDg7Y5xznRJjxsy/6tu1g2CmGOMD9UL45VS?= =?us-ascii?q?i+46ptVRTlkzkMOSIn/27Li8xwlKNbrwynpxxj2I7ffYWZOONjcq/BYd8WQG?= =?us-ascii?q?xMVdtTWSNcGIOxd4sBAfQcM+ZEoYfzpFUBrRqiCgajH+7v0CNEhnrs0KEmye?= =?us-ascii?q?ksEwfL1xEgEdIUt3TUqc34OKkTX+Cy0anIySjMY+tL0jn58ofIdw4uoeqCUb?= =?us-ascii?q?ltdsfRy0YvFwTYjlWUtIPoJC2V2foXs2ia9OpgVO2vi2g9pw5tpTivw94hh4?= =?us-ascii?q?/UjYwbzVDE8D92wIczJdCgVk50f8SkEJpLtyGbOIt2RMIiQ2d0tyog1rIGvp?= =?us-ascii?q?u7cDARyJUpxh7fd+CIc4iS7h3/VOadOTZ4i2x5eLKxnRqy9lKgyuL6W8Kp01?= =?us-ascii?q?hKtjJInsTQunwXyhDe6MaKRuFg8kqh1zuDzQ/e5+VcLUwpiabXMYMtz7wsmp?= =?us-ascii?q?YJrEjOESz7lF/rgKKVbkkk9Pan5uf7brjjo5KTLYx5hwXlPakrlMGzH/k3Pw?= =?us-ascii?q?kLUmeA/emx1b/u8Ej3TbhEjPA5j6/Uu43AK8sBvK62GQpV354m6xa4Ejipzs?= =?us-ascii?q?wVnWICLFJZYBKHiJXpO03WLPD4E/i/h1OsnS92yv7aJrPtH5XCIGDMnrjgYb?= =?us-ascii?q?px9VRQyBQvwtBY/ZJUEqsNL+juVUPrqtzYFAQ5Mwquz+n7D9V905sSWWOJAq?= =?us-ascii?q?CHLKPfqUKE6v41L+WRZoIYtizxJ+Ul6vPgl3M0llsQcbGs3ZQNaXC4GvpmI1?= =?us-ascii?q?+eYXrpmtoBE2gKvg0jTOzulVKPSiBTaGioX6I9/TE7CY2mDYHZSo+xh7yB2T?= =?us-ascii?q?+3HodKaWBeFlCMDXDoep2BW/gWciKSPs5hkjoeWbe9UYAhzguhtAn9y7p5NO?= =?us-ascii?q?XZ4TYYtJzi1Nhp++LTlQs++iB0D86FyWGCU3l0nn8URz8xxK1/u1Jyylid3q?= =?us-ascii?q?l3n/xVDt1T6O1VUgc0L5LcyPZ6C9+hEj7GK/KAUkqnRJ2NCCo4SNUvypdaZk?= =?us-ascii?q?9nB9SkyBvKxCOsBKEcv6eUBYA/8uTX3y61b4xnxnnLxLUJjlQ6TI1IL2Lszv?= =?us-ascii?q?pl+gfeF5LhkkiFmeCtb6tKjwDX82LWh0WJoUVUFEZSWKDIRjpXMknZqsn96m?= =?us-ascii?q?vcQqWvErUoNE1KzsvUefgCUcHgkVgTHKSrA9/ZeW/k3j7oXRs=3D?=
X-IPAS-Result: =?us-ascii?q?A2HnBwCC3vxd/zGZrQpiAxwBAQEBAQcBAREBBAQBAYF8g?= =?us-ascii?q?R5TgR2BMQqDfY5QCIIeJYMPXpVdgSsXFgcICQEBAQEBAQEBAQMBAwEYAQoMA?= =?us-ascii?q?QECg3lFGYIqOBMCAwEBCwEBAQQBAQEBAQUDAQEBAoYgDII7KQFpLwkBOAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCCAUCNBkFAjUSA?= =?us-ascii?q?QEdAQIBAwEBAwEdAggBGyUZBAEIEQMBAgYBAQEbBwIEBRABAwsBCx0KBAEJC?= =?us-ascii?q?AEGCAaDDgGDBqprdYEyhDoBhgYQBYExhR2HFoFCPoE4DBSBTlAuPoJkAQECg?= =?us-ascii?q?UkBAS0JASaCSTKCLASNPw0dgkuFV4ESgTCHH4UjgmqHFAMHgjSGFwE0ZoFZj?= =?us-ascii?q?SiCRHaXG40agTeHR2MokgICBAIEBQIVgWmBe3AVOyoBgkEJRxgNjR0BFxWDE?= =?us-ascii?q?yiFFIU/dAEMJJIXMV8BAQ?=
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_128_GCM_SHA256) id 15.1.1779.2; Fri, 20 Dec 2019 09:50:31 -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 09:50:31 -0500
From: "Gould, James" <jgould@verisign.com>
To: Martin Casanova <martin.casanova@switch.ch>, "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: AQHVt0TT2Y3Ol4UxBkykKpzdF79yuQ==
Date: Fri, 20 Dec 2019 14:50:31 +0000
Message-ID: <70500518-B4B3-4089-BD61-6E5D3DC8A03F@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.f.191014
x-originating-ip: [10.170.148.18]
Content-Type: multipart/related; boundary="_004_70500518B4B34089BD616E5D3DC8A03Fverisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/kq_Co8CSU-9iucyCbMYlAFSOSLY>
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 14:50:40 -0000

Martin,

My feedback is embedded below.

--

JG

[cid:image001.png@01D255E2.EB933A30]

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/>

From: regext <regext-bounces@ietf.org> on behalf of Martin Casanova <martin.casanova@switch.ch>
Date: Friday, December 20, 2019 at 3:51 AM
To: "regext@ietf.org" <regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] How to handle Domain Info Command with empty authinfo/pw tag in command?


Jim

Thanks you for the feedback.

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] and therefore consider it "matching". But since an empty string is not a valid authinfo according to server policy's length and complexity requirements 2202 is certainly justified.



JG – No, I’m not arguing that an empty auth info in the command (info or transfer request) should be considered a match with a null auth info value in the info or transfer commands, since that would be a dangerous security hole.  I agree that the result of passing an empty authinfo in the info or transfer commands should result in the 2202 error result.  I’ll take a closer look at draft-gould-regext-secure-authinfo-transfer to ensure that it clearly defines an unset authinfo as not being a match with the passing of an empty authinfo value in the info or transfer commands.  An unset authinfo should be set to null and not set to a hashed empty string.





However this runs into the same situation as option 1 returning always 1000 where there is no way for the sponsoring client to query if authinfo is set on the domain at all. (without having to check for correctness)



JG – For the sponsoring registrar, you could return an empty authinfo in the response to indicate that the authinfo is set and return no authinfo element if the authinfo is not set.  There would be no need for the sponsoring registrar to pass the authinfo element.  This could also be covered in draft-gould-regext-secure-authinfo-transfer, since draft-gould-regext-secure-authinfo-transfer currently states that the info response MUST NOT include the optional authinfo element.  I don’t believe there is an issue providing an indication of whether the authinfo is set or not set with the sponsoring registrar.  The concern was providing the indication to the non-sponsoring registrars.  Thoughts on taking this approach to address the use case?



It is a constructed example but you could imagine a domain with status serverUpdateProhibited and authinfo set/removed by the registry. Then the client could not simply reset the authinfo nor query if it is set or not. Of course we would send a ChangePoll enriched Poll Msg to the sponsoring registrar if we do that... :)

Probably it is enough to be able to verify correctness of an authinfo e.g. before a transfer..



Martin



________________________________
Von: regext <regext-bounces@ietf.org> im Auftrag von Gould, James <jgould=40verisign.com@dmarc.ietf.org>
Gesendet: Donnerstag, 19. Dezember 2019 14:39:08
An: Martin Casanova; regext@ietf.org
Betreff: Re: [regext] How to handle Domain Info Command with empty authinfo/pw tag in command?

Martin,

I believe option 2 in case 2 is the best approach, but I don't believe an empty auth info should match a non-set auth info value.  Per the practice defined in draft-gould-regext-secure-authinfo-transfer, unsetting the auth info should result in a null auth info and not a hashed empty string that would then match a subsequent empty auth info value.  I view both cases as being the same case of an invalid auth info resulting in a 2202 error response.

--

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/19/19, 4:04 AM, "regext on behalf of Martin Casanova" <regext-bounces@ietf.org on behalf of martin.casanova@switch.ch> wrote:

    Hello

    I was hoping for some input of the community about an implementation
    decision for the Domain Info Command/Response when it comes to the
    optional <domain:authInfo> associated with the domain object.

    RFC-5731 about  <domain:authInfo>: ... If this element is not provided
    or if the authorization information is invalid, server policy
     determines if the command is rejected or if response information will
    be returned to the client.

    1.
    In case the <authinfo><pw> element is delivered but not correct (no
    match or not set on domain) we will return a Code 2202 to inform.
    (sponsoring client or not)

    2.
    In case an empty tag is given (<authinfo><pw/></authinfo>) we are
    wondering if:
    Option 1: always Response Code 1000 should be returned
    Option 2: Only answer with 1000 when there is NO authinfo/pw set on the
    domain (kind of confirming it) and otherwise 2202 considering an empty
    tag as invalid authorization information delivered.


    I think maybe option 2 may be better because that way a registrar could
    check if an <authinfo> is set or not even without knowing it.
    After all, the registry could have set or deleted <authinfo> without
    noticing the registrar. However many clients seem to send
    <authinfo><pw/></authinfo> just about always and they would need to adjust.

    I have to mention that our Domain Info response will never include the
    actual <authinfo> since we only store a hash of it for security reasons.
    A Domain Info Command with the <authinfo> Element entirely omitted will
    always be answered with 1000.

    Thanks and merry X-Mas!

    Martin Casanova

    ---
    SWITCH
    Martin Casanova, Domain Applications
    Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
    phone +41 44 268 15 55, direct +41 44 268 16 25
    martin.casanova@switch.ch, www.switch.ch<http://www.switch.ch>

    Working for a better digital world


    _______________________________________________
    regext mailing list
    regext@ietf.org
    https://www.ietf.org/mailman/listinfo/regext


_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext