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

"Hollenbeck, Scott" <shollenbeck@verisign.com> Thu, 27 February 2020 18:12 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 AB3233A0E88 for <regext@ietfa.amsl.com>; Thu, 27 Feb 2020 10:12:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 42DXEvL6aSwG for <regext@ietfa.amsl.com>; Thu, 27 Feb 2020 10:12:04 -0800 (PST)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (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 1AC093A0E7A for <regext@ietf.org>; Thu, 27 Feb 2020 10:12:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=1340; q=dns/txt; s=VRSN; t=1582827125; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=2D3kg+DW3GJZ/R9i18no5Jnu2Vxmwp70Qils4x1i1L8=; b=L/FciKfi5uWfbGOMayCHbHnAvKHhrfTNKVEFiaZ0DEim2ZNJxbveg1/W C1vM4VG/hhopuJ1lxJkgl9hDEXVC9HBVLdB6hL8auj0YJJGRrZayK5kKF JxQPhZsuJJFAMEWJmwTGAwZI20gUemVCia1PUDxDoiJK1K7RrCQoBVY7F GZsLEUbJR6QrBgkJZ/wo6mX75GCqtZauClrcrM5z6HWWMQbdQh56Hzldv WpM6WXj5mNLBO2IU2rA2hu2KvDSujLZtzDQA8cajP+kLFEGYWuzwi8PjL Un4HtgHIgb+c2LoXn9G28JciIWeEGGq24GSgDzUt4qju7p3TaPLytOY0s w==;
IronPort-SDR: 799ru8PUS/TSTgyLkoDyNLyHJ/w8yVNziGh9fl2gypTo50lILx4QNu/I5Comihwt9Os7t7rVRE QGF6gl1IkUzUeV3lNdeFP3MAQgKEHJ/A69iFC0vdB+4InjKARfVWAa7+wsY0JbAu6hB9bYbLDs XxOdM10Ibn7F9Otxn/9QXGR7U3PcRWGn0fc8PAYjX1rnAJsuaCUxJNRp1Sd0iUpV3SQCv0bdlk zPQ2bcaA4STHh6Ou1DtGRZOCAddtIly8V59coVuRQx9NI9pqYpe4TS9te9v7XrmWTCkowgH7D6 Oik=
X-IronPort-AV: E=Sophos;i="5.70,492,1574121600"; d="scan'208";a="865760"
IronPort-PHdr: 9a23:WmhjAh9slnILP/9uRHKM819IXTAuvvDOBiVQ1KB22u4cTK2v8tzYMVDF4r011RmVBNmduqwP0rKL+4nbGkU+or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRpOOv1BpTSj8Oq3Oyu5pHfeQpFiCeybL9oKBi7rArdutQKjYZiN6081gbHrnxUdutZwm9lOUidlAvm6Meq+55j/SVQu/Y/+MNFTK73Yac2Q6FGATo/K2w669HluhfFTQuU+3sTSX4WnQZSAwjE9x71QJH8uTbnu+Vn2SmaOcr2Ta0oWTmn8qxmRgPkhDsBOjUk9mzcl85+g79BoB+5pxJx3ZPaYJ2bOvR9cKPSf9IaSnZOUMleTCFBHpq8b4kTA+YdIepUsY/wrEYOoxukAgmsAfvixjFKiH/x2a061/ouEQfd0wM+A90Os2zYp8joOqgOVuC10LXIwTveZP5Rwjf96I/IchQlof6SW7J/atTexlUsFw7ekFWft5blPzKO1uQMvGib6fBsWv6oi24isgx8pCWkyMkrionMnI0Vy1bE+D14wIkrOd24RlR3Ydm+EJtfsSyRKoh4Qts6Tm11pCo20KAKtJy1cSQQ1ZgqxxDSZ+aIfoWM+h7vSfqdLS1liH9nZL6znQu+/Eejx+HmS8W5005GriRbndTPqnwA0hne58qbRfdh5Eis3CuD2BzP5exBIU07iLTUK5Akz7M0i5UcrFrMEynrk0vslqCWbF8r+u2w5uTiZbXpu4GTOpdvigH7LqQugsu/AfkkMgQWX2iU5+C81Lr78EDkXLtEluA6nanBvp7VJMsXurC1DxVL0ok/7Ba/FS+m3M4CknYaNl5FZgiHj5PvO13UPP/4CvK/j0ytkDdt2f/GIqXsDojRInTZjbvsf7hw51RBxAczw91T/Z1ZB7UZLPL2QEDxtdjYDhEjMwyzxubqEM591oMZWWKLBq+WLqXSvkSW6e0zIOmBf5EVtyjnK/gk/P7ujHA5mVkHcaa12psXbWi0Hu56LEWBfXrsntABHH8Svgo7V+HllVqCUSJJaHa0Qq0z+jY7BJi6AofEQ4CnmKaB0zujHp1KemBGDUiBEW32eIWLRfgNZz6SL9RgkjMaSbihRZUt1Ra0tA/1mPJbKb+e4igwuZX/3d557OqVnhY3v3QgF8G132aRRmd4lWROTDgziuQ361ZwxVqTzYB5juBWU9tJ6LkBBh03OpPM08R7Bsz8HAXbcYHaZkyhR4DsITY1St83ydIFYAI1IN6lkgyJl36xA7gRk7GNDpE/8YrC0mLwPMdyzTDN06x33ApueddGKWDz3v03zAPUHYOcy0g=
X-IPAS-Result: A2HSAgBZBVhe/zGZrQpmHAEBAQEBBwEBEQEEBAEBgXuDFYExCpUYmz0JAQEBAQEBAQEBBwEjDAQBAQKEPgKCLTgTAgMBAQsBAQEFAQEBAQEFAwEBAQKGIAyCOyJ2cQEBAQEBAQEBAQEBAQEBAQEBAQEWAkNVEgEBHQEBAQEDOksEAgEIEQQBAQEWAQEGBQsyHQgCBAESCIMfgwqvJoInhDUBE0GFNQaBOIw/gUI+gRGCZS4+gmQCAwGCKQIFhSAEjWiiLgMHgjyHUYVNhBqFJSSbLo5wiHySSwIEAgQFAhWBaYF7cIM8UBgNjikXFYhPhUF0jHIPFYENgRABAQ
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) 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; Thu, 27 Feb 2020 13:11:15 -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, 27 Feb 2020 13:11:15 -0500
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "pm@dotandco.com" <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: AQHV7PxJQg9Wr/u/ykyNy+UNwJR7nKgvV6yA
Date: Thu, 27 Feb 2020 18:11:15 +0000
Message-ID: <b905c833399f4b40baa5d02d0c112fdf@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> <436A323C-AD02-4FFE-A182-B9376AFF3783@verisign.com> <82ef0b63-13cb-403b-886d-de66f7086890@www.fastmail.com> <68a5d403846d4042ab7db859499ab77b@verisign.com> <2e348f0a-c411-4389-a1e6-353e73bcb608@www.fastmail.com> <8253a2df-3d21-4d13-811d-9cf6e72881a6@www.fastmail.com>
In-Reply-To: <8253a2df-3d21-4d13-811d-9cf6e72881a6@www.fastmail.com>
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/OtNPaE9EjFUaB3lVm6XffMBU8F8>
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, 27 Feb 2020 18:12:06 -0000

> -----Original Message-----
> From: regext <regext-bounces@ietf.org> On Behalf Of Patrick Mevzek
> Sent: Wednesday, February 26, 2020 6:27 PM
> To: regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] How to handle Domain Info Command with
> empty authinfo/pw tag in command?
> 
> On Thu, Jan 23, 2020, at 01:01, Patrick Mevzek wrote:
> > 2) for the login security draft I said from the beginning that instead
> > of just relaxing the limits on password length, we may want to use
> > more standardized methods such as SASL, and in particular there are
> > mechanisms to authenticate without exchanging any password (SRP) See
> >
> https://mailarchive.ietf.org/arch/msg/regext/iMfmuxNgDbMHGMGehg8VT
> _oSk
> > lU
> 
> FWIW, here is a recent attempt to retrofit SASL inside HTTP, and while it is
> not applicable exactly as is to EPP, it shows other people wanting to have
> SASL as default in "legacy" protocols, in order to plug in later other
> authentication mechanisms.
> 
> https://datatracker.ietf.org/doc/draft-vanrein-httpauth-sasl/

Thanks, Patrick, this may be worth exploring if there's interest in adding this kind of capability to EPP. I don't know if that interest exists in this WG, but with the drip WG also looking at EPP they might bring some motivation to the party.

Scott