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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Thu, 19 December 2019 12:24 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 5BFD912010E for <regext@ietfa.amsl.com>; Thu, 19 Dec 2019 04:24:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 ntYeLOd_iFJy for <regext@ietfa.amsl.com>; Thu, 19 Dec 2019 04:24:33 -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 970A21200FA for <regext@ietf.org>; Thu, 19 Dec 2019 04:24:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=3790; q=dns/txt; s=VRSN; t=1576758273; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=YB8nyWbPEn1Hq03BaojjHS0RB/LY/qCiGPweTLyeXQU=; b=MB81isBsAHqeVjoFODDYi/eVUtFeebEa+3bSr6sfZAMWD2TXNBPjd05P W0j7l+ukLGQRtUog2P3QnwTUyp4+qyWIvhHbmi3izWG0r/Mkfyt+xG3sJ ygMgO7Wfq8DVTDWzCOnZ7OdWtj0y72irwYianUG5lw5jDTWbCaSKuc4yP pL3IUjPvSerZ5sy6kjn5Dl8uUFqQmESyo5+IZ+/iXZk7h+mu6b1kcSD0S tSYujZUvgbhc93BSe6t7r7qrxmlogfoR8q28TjdRVwawDeQ8eFnUQsRDK m0U0r6aZNOq5mtFF+VAd7/9/488a6V48M471irNPIqXw8kQRadq8dydre g==;
IronPort-SDR: Z8rpV2ut9IsRPcf1aq2LeYJAfDd/mKiBiGyLjymAVNd4Olh/kdDaJDwYP51tpo9Olfz7aE8sVe R3fRwcjqV16Fa1ZVGn6rDOt4bbGJYiiJwVyyqGXQ9q486bCx2V4Y0z7uEzXor7/bjzCTkzDucK q3hlFbTsDroSSaqqiC6Pzl+Cs9mvvJMrrADzK6N4ajsB3hYsSaQ8lF5GRAGu0CRkAhbBIzKvja kKBE62/oURLTAVEgo2hMv17YyslOnMfw8eJrXI3Mk6H3Tav35WI+OyVTk5E5IjA+PJWLIZUXxn yWM=
X-IronPort-AV: E=Sophos;i="5.69,331,1571716800"; d="scan'208";a="292143"
IronPort-PHdr: =?us-ascii?q?9a23=3A9uf3PxH5t2mX7Tg9P2EBfp1GYnF86YWxBRYc79?= =?us-ascii?q?8ds5kLTJ76p8i/bnLW6fgltlLVR4KTs6sC17ON9fq5ACdbvt6oizMrSNR0TR?= =?us-ascii?q?gLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ?= =?us-ascii?q?/iOgVrO+/7BpDdj9it1+C15pbffxhEiCCybL9vIhi6txvdutQLjYdtJKs8yA?= =?us-ascii?q?bCr2dVdehR2W5mP0+YkQzm5se38p5j8iBQtOwk+sVdT6j0fLk2QKJBAjg+PG?= =?us-ascii?q?87+MPktR/YTQuS/XQcSXkZkgBJAwfe8h73WIr6vzbguep83CmaOtD2TawxVD?= =?us-ascii?q?+/4apnVAPkhSEaPDM/7WrZiNF/jLhDrRyhuRJx3pLUbo+WOvpwfKzdfM8VS2?= =?us-ascii?q?VOUctKSyxOGYG8Y5cTA+YdP+tVqZT2qVsUrRu5AAmhHO3jxD1Phn/y2a01ze?= =?us-ascii?q?IhHhrY0wM8HNICqGnfosjpO6cVTeC10KfExijEYvNN2Tf974zIchQ/rvGKRr?= =?us-ascii?q?1/b9beyUo0GgPbkFqQs43lPyiU1uQCtWiX9fZvVeWqi2M+rQx6vzahxsApio?= =?us-ascii?q?bTh4IVzEjJ9T53wYY0Od23VE57bcS4H5tQry2aNpV5Qt8sQ21yvyY60LIGtJ?= =?us-ascii?q?imdyYJ0JQq3wPTZ+Cdf4SV4B/uWvydLSp4iX9rYr6yiBW//VC9xuHgTMW4zV?= =?us-ascii?q?RHojZfntXRuX0A1Abf5tWER/dl8EeuxzWC2xzW5+xBI007ibbXJIQkz7Itip?= =?us-ascii?q?UcrUHOEy/rl0rogq+bc0Ep9fW15Ov5ZLjtu4WSOJVuig7kN6Qjgsm/AeMlPQ?= =?us-ascii?q?cQR2Wb4uG81KH7/U3+XbVKkuU6kqnHv5DeIsQWvrO0DRNN3Io+6xmxFzio39?= =?us-ascii?q?UEkXUaNl5FZg6Ij4/zO1HWOvz3F+qwj06ykDdx3PDGOKftDYnKLnjGiLvhfL?= =?us-ascii?q?B95FBAyAcr0NxT+4hYBqwDLf/9QEP9qdzVAxEjPwG7wOvrENB92ZkfWWKLDK?= =?us-ascii?q?+ZKqTSsVqQ6+I0I+mMY4sVuDLjJPgj/PHhk2M2mVwGcKm3w5QXcnG4Hu9nI0?= =?us-ascii?q?WWZ3rgmMsOEWAPvgYmVuzllEWCUSJPZ3a1R6884ys0CJi6DYfCQIChmqCO0z?= =?us-ascii?q?2gHpJMYGBGDU6MHm3zeoWfVfYMaT6SLdNhkjAeSbehS5cr1Quyuw/i17pnMu?= =?us-ascii?q?3U9zUCtZ3929h6+eLSlQ0p+Dx1Ecudz2+NQ3tznmMSSD9llJx49AZ4w02f0K?= =?us-ascii?q?4+iPVDHNpU+fphSRg7KZXcied6QZimXwvbYtaPDl2vWdygBi84ZskuwsMFYw?= =?us-ascii?q?B2G4PmxlrZ0iWnE6M9lrGXCtoz6K2WlyzrKslw22ru1aQ9gR8hWMQZZkO8ga?= =?us-ascii?q?sqvSjUA4rElU+UnKXuPZ8X2zLRvi/X1mqJuEVVVgR9WqbtQ30FZ1DXotK/7U?= =?us-ascii?q?THGez9QY87OxdMnJbRYpBBbcfk2A1L?=
X-IPAS-Result: =?us-ascii?q?A2HlAgBca/td/zCZrQpkHAEBAQEBBwEBEQEEBAEBgXyDD?= =?us-ascii?q?oExCoN8kRubJwoJAQEBAQEBAQEBBwEYCwwBAQKDeUUCF4IpOBMCAwEBCwEBA?= =?us-ascii?q?QQBAQEBAQUDAQEBAoYgDII7ImMOcQEBAQEBAQEBAQEBAQEBAQEBAQEWAg02H?= =?us-ascii?q?jcxAQEBAQMBASERFSUXAgICAQgRBAEBAwImAgICGQwLFQgIAgQBEggMgw+DB?= =?us-ascii?q?qtwdYEyilAFgQkohR2HFoFCPoN2Lj6CZAEBgU0tgnmCXgSNPiqCS4gZlj8DB?= =?us-ascii?q?4I0iQuNBSOCQ5gOjlGIKpInAgQCBAUCFYFpgXtwUIJsCUcYDY0dGBWDE4U8h?= =?us-ascii?q?T90kAYxXwEB?=
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_128_GCM_SHA256) id 15.1.1779.2; Thu, 19 Dec 2019 07:24:29 -0500
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1779.002; Thu, 19 Dec 2019 07:24:29 -0500
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "martin.casanova@switch.ch" <martin.casanova@switch.ch>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] [regext] How to handle Domain Info Command with empty authinfo/pw tag in command?
Thread-Index: AQHVtktYyjHMVbkB70OlEzpyy5LC6afBYKbw
Date: Thu, 19 Dec 2019 12:24:29 +0000
Message-ID: <a03fb9786cff4a1a84a4fd2672f65622@verisign.com>
References: <d17d88d0-e9db-9416-1917-dc992fcd2d3a@switch.ch>
In-Reply-To: <d17d88d0-e9db-9416-1917-dc992fcd2d3a@switch.ch>
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/XWI8Ql-m30p5Zu6mVvqS59UsTec>
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: Thu, 19 Dec 2019 12:24:35 -0000

Martin, you also have to consider client identification and authorization when trying to determine an appropriate response code. I can see returning result code 1000 to a sponsoring registrar who omits the authInfo, but a request from a non-sponsoring registrar who omits the authInfo should produce a 2201 response code. A 2202 would make sense for a non-sponsoring registrar who provides invalid authInfo.

Scott

> -----Original Message-----
> From: regext <regext-bounces@ietf.org> On Behalf Of Martin Casanova
> Sent: Thursday, December 19, 2019 4:04 AM
> To: regext@ietf.org
> Subject: [EXTERNAL] [regext] How to handle Domain Info Command with
> empty authinfo/pw tag in command?
>
> 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
>
> Working for a better digital world
>
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext