Re: [regext] CALL FOR ADOPTION: draft-gould-regext-secure-authinfo-transfer

"Gould, James" <jgould@verisign.com> Tue, 28 January 2020 16:00 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 7B12D12091B for <regext@ietfa.amsl.com>; Tue, 28 Jan 2020 08:00:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 XWmKSQMgGMde for <regext@ietfa.amsl.com>; Tue, 28 Jan 2020 08:00:48 -0800 (PST)
Received: from mail4.verisign.com (mail4.verisign.com [69.58.187.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 551151208D6 for <regext@ietf.org>; Tue, 28 Jan 2020 08:00:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=8190; q=dns/txt; s=VRSN; t=1580227249; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=F4vJTKGUtFt7Nc9Z2ayZT6ruxDHbuAhVG8qQSWaQRa0=; b=mOFWIZZ1qGFqaNH1+TcKR7DF8dTU9jDMF315ZgXg1B6cI3oufLpo+WWr 4FQsquBnqgO0v86ddXxHAeFnAEt2UvaMQIjMI8G2jrzO5HZpIKq3d1ubc Qlfsrq6uSHkeWq98HGWLkgy0L0zYXhkBREC5Sg94qHSjHDnjbHxvQcauI CqKzONdQUEFTIhYxFdGNkU0De7/JzUWgo+qozB42EmR0eYdsyTEf+bsqU vuXnqdCjs4xCVvVFyhx9XCUb7wG+elKf+paWXZuV2+CQi3R5wRmx/GFq1 MAtuZQvAosWL7D6rQLbQES5V7WYcCWuwmsWqYbd+R7pdZbhzpvnqSMkjE A==;
IronPort-SDR: il578ty5jLDmCXaBq8esH3N8VaY2g1EK66v/mJIalmU4H9wqRlVvcCP0HrkvQM9vE1orRkjlaV T+wku38J4DYdMJTcahHR7i80ymZYeGQi9Su3uIRreb6sORdtQCH6yM/3Q9jHuN4xaY6/YoxdL6 59erY9vAfQ5RGtD7PU5IfyIFd9LYt1Uc4kQRDTJvMU7/FuZUIxG3PzRln86RCbsDGduGL9mi8H Z3PLz9fkdbS6gS5PfR+L+BITPygwnHlEoKW1duVVDrCVJkLsiDi61yE9H2e4sl0Tud/TGHeDEa izM=
X-IronPort-AV: E=Sophos;i="5.70,374,1574139600"; d="scan'208";a="540798"
IronPort-PHdr: =?us-ascii?q?9a23=3AEf6QlBNiCfbVp3XMeUwl6mtUPXoX/o7sNwtQ0K?= =?us-ascii?q?IMzox0K/z+pcbcNUDSrc9gkEXOFd2Cra4d16yN7+u/BiRAuc/H7ClZNsQUFl?= =?us-ascii?q?cssoY/p0QYGsmLCEn2frbBThcRO4B8bmJj5GyxKkNPGczzNBX4q3y26iMOSF?= =?us-ascii?q?2kbVImbuv6FZTPgMupyuu854PcYxlShDq6fLh+MAi6oR/eu8ULjoZuMKg8xx?= =?us-ascii?q?TGrnZKeeld2GdkKU6Okxrm6cq84ZBu/z5Mt/498sJLTLn3cbk/QbFEFjotLn?= =?us-ascii?q?o75NfstRnNTAuP4mUTX2ALmRdWAAbL8Q/3UI7pviT1quRy1i+aPdbrTb8vQj?= =?us-ascii?q?St871rSB7zhygZMTMy7XzahdZxjKJfpxKhugB/zovJa4ybKPZyYqXQds4BSG?= =?us-ascii?q?FfQsheSTBOAoKkb4sOEeUBO/pYr5LgrFcKtBeyGBWgCP/qxjJOm3T437A10/?= =?us-ascii?q?45HA/GwgIuAs4OvnrXotX7NqgdX+G1w7XHwzrMdP5WxSzy6I3Ufhw9u/yBX7?= =?us-ascii?q?R9etfRx0k1EAPFi02dpYLkMTOSy+QNt3WU4/J9XuyrkWEnrh9+oiOhyswxjY?= =?us-ascii?q?TJhI0VylfZ9SV93Yk4PsO4R1BhYd6lC5tQti6aN41sTsw+RGFovT83x7sbsp?= =?us-ascii?q?C1eygKzY4oxx/Za/GfbYiH/AjjVOeKITd5i3JlfrO/hxCu/kS61uL8Ucy03E?= =?us-ascii?q?5LriVbjtnMuGoB1xvJ6siITPZ240Sv2S6X2gzO9u1IO104mKjVJpI737I9lp?= =?us-ascii?q?QevV7MEyLygEn6kbOael859uWq9+jreKjqq5CfOoNulw3zMbwimsKhDuk7Lg?= =?us-ascii?q?QDWm2W9v6/2bDn5kL0RbtHguMrnaTYtZ3VPsAWq6+7DgJQ3Isu5RSyACqg3d?= =?us-ascii?q?8Fh3cINkhFdwiCj4XxPlHOJ+33AumnjlS3lTdr2+jGPrr8ApXRNnTDkKnufb?= =?us-ascii?q?J660NE1Qc90chR649UBb8ZL/z8W1P9uMLCAh8nLwO0xPznCM1n2owERG2DGL?= =?us-ascii?q?GZMLnJsV+O/O4gP+6MZIoNtDb8Lfgq+eLugGcklVMBZ6WlwJkaZX6iEvh7I0?= =?us-ascii?q?iUb2Dgj9gFHGsSuwoxVu3qiFmMUT5JYHayWrox5jM0CIKhEIfDQp2ijaef3C?= =?us-ascii?q?ilBJ1WZ3tGClGDEXfubYmLR/AMaCeKLs97jjMETaShS5Mm1Ry2rA/6zqFqIf?= =?us-ascii?q?fT+i0Er53j0sV66PHUlR0o6TN0CMGd2XmXT25ohmMIWyM23KdnrExn1FiD3r?= =?us-ascii?q?Z3gvNEFdFI5vNGTBs6NZDGw+x9EdDyVVGJQtDccF+6WNStAnkUQ8wjztxGN1?= =?us-ascii?q?54M9mlkhnF0yGtRbQSkurPTNYu/63Rz2TZJsthxTDBzqZrxw08T8RCJXGOh6?= =?us-ascii?q?Nj+U7UHYGfwGuDkKP/P4sbwSrBsC+hxG+DpwsQBAx/VrjBUVgBa1HXttX24A?= =?us-ascii?q?XJSLr4WudvCRdI1cPXcvgCUdbul1gTAa67YNk=3D?=
X-IPAS-Result: =?us-ascii?q?A2GXAwAzWjBe/zGZrQpiAx4BCxyBcAuBeIEdgTEKhAqRP?= =?us-ascii?q?oNulWOBKxcdCAkBAQEBAQEBAQEHARgNCgEBAoN5RQIXgjQ3Bg4CAwEBCwEBA?= =?us-ascii?q?QQBAQEBAQUDAQEBAoYgDII7KQFpLwk5AQEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBBQIIBzQZBzUSAR8BAQEDAQEbBhE4AhsCAQgOCgICE?= =?us-ascii?q?QMSAgICJQsVEAIEAQkJG4MLAYMKrVuBMoRJQUCEf4EOKoo+gXqBQj6BEScgg?= =?us-ascii?q?kw+gmQBAQMBgRoxIAsKCxMICIJBMoIsBI1YATKCRoYBmBB2AweCOYdCjxCCS?= =?us-ascii?q?HiHEo5EgWaKX4QBh1RoKJIpAgQCBAUCFYFogXxwFTsqAYJBCUcYDY5VgzuFF?= =?us-ascii?q?IU/dA0BJIs8JYENgRABAQ?=
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; Tue, 28 Jan 2020 11:00:42 -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; Tue, 28 Jan 2020 11:00:42 -0500
From: "Gould, James" <jgould@verisign.com>
To: Patrick Mevzek <pm@dotandco.com>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] CALL FOR ADOPTION: draft-gould-regext-secure-authinfo-transfer
Thread-Index: AQHV1ayjvqw/K+r+9kurOVrPJZ279KgAPNoA
Date: Tue, 28 Jan 2020 16:00:42 +0000
Message-ID: <9D3A8ECD-976A-469E-B5B0-6FD6B8BB8BE0@verisign.com>
References: <3498D60D-AED3-448F-AA97-D5390E14938F@antoin.nl> <894ec029-7ef0-4c02-8b37-9872e8f5934b@www.fastmail.com>
In-Reply-To: <894ec029-7ef0-4c02-8b37-9872e8f5934b@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.12.200112
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <66BD9D4604B9304DB1C7E8E2A9741E69@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/0vYyooh4udisf5ZMTSFRadgIhHo>
Subject: Re: [regext] CALL FOR ADOPTION: draft-gould-regext-secure-authinfo-transfer
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: Tue, 28 Jan 2020 16:00:52 -0000

Patrick,

I respond to your comments below.

-- 
 
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 1/28/20, 2:29 AM, "regext on behalf of Patrick Mevzek" <regext-bounces@ietf.org on behalf of pm@dotandco.com> wrote:

    
    
    On Fri, Jan 24, 2020, at 09:51, Antoin Verschuren wrote:
    > This is a formal adoption request for Extensible Provisioning Protocol 
    > (EPP) Secure Authorization Information for Transfer: 
    > https://datatracker.ietf.org/doc/draft-gould-regext-secure-authinfo-transfer/
    > 
    > Please review this draft to see if you think it is suitable for 
    > adoption by REGEXT, and comment to the list, clearly stating your view.
    
    While the subject of transfers between registrars might need work,
    I am not convinced this working group is the appropriate place for that,
    as in particular this document seems to mostly impose directives on registries
    and how they should handle and store domain passwords which is for me 
    off topic for EPP as a protocol, and transfer issues cover points that are
    not completely technical but also business related, including the
    specific security model in which we want to work.
    (one might note that multiple procedure specify a transfer "undo" procedure,
    while this does not exist technically anywhere in EPP land...)

JG - You have brought this up before, but the adoption of a BCP draft by the WG is certainly applicable.  A transfer "undo" procedure is something new and can be handled separately.  
    
    As discussed in other threads, I am more leaning towards a ground up discussion
    on passwords attached to domains, and if other models can exist here.
    So I think work should instead go in that direction, which is then
    really completely EPP related, while discussions on passwords size, complexity,
    entropy, storage, TTLs, and so on as found in this draft are for me clearly
    out of scope of both the working group and EPP related specifications.

    
    The authInfo node was defined from the ground up to be extensible,
    and we should leverage that to put into place better mechanisms than
    current plain text passwords.

JG - An alternative approach is not mutually exclusive and I look forward to any proposals that you may have.
    
    I also fear discussions may forget there are already today other models than
    the "common" gTLD one that the draft tries to change,
    and I would like to make sure they are taken
    into account when drafting a solution.
    Among others, some registries use a "push" transfer model (so no
    passwords needed at all any more) and other registries basically do not
    let registrars set/handle passwords anymore, the first step of a transfer
    is the loosing registrar to ask the registry to generate a password that
    is in fact directly sent to the registrant, who in turn will input it
    at the gaining registrar (with some time window limits).

JG - Any input from interested parties is welcome.  The main question is whether other models can be fit into a common practice or whether they stand on their own.   
    
    Also while things should be left separate to be really able to produce
    new ideas, transfer issues can not be tackled without at least looking
    a little around RDDS and specifically RDAP, and around laws such
    as the GDPR from EU land, because this has the direct consequence
    for example that some registries do not continue to collect contacts, 
    or none besides the registrant.

JG - One goal of enhancing the security of the authorization information for transfers is to reduce or remove the dependency on the use of RDDS.  
    
    PS: as an exercise I reviewed how a batch of registries currently reply
    to domain:info queries in the following case:
    - registrar is not sponsoring registrar, and not providing authInfo
    - registrar is not sponsoring registrar, and providing invalid authInfo
    - registrar is not sponsoring registrar, and providing correct authInfo
    - domain does not exist and registrar is providing authInfo
    - domain does not exist and registrar is not providing authInfo
    
    Results vary a lot, even when just looking at the EPP return code.
    Also the content of <infData> can change, and differ - even outside of the password
    - between sponsoring and non sponsoring registrars.
    There is clearly no standardization here and this directly impacts
    how transfers can be done by registrars
    (on issues for example of being able to test the password without
    really starting the transfer, or to know the current nameservers
    attached to the domain, or its expiration, etc.)

JG - draft-gould-regext-secure-authinfo-transfer focuses on the behavior of the info command and response as it relates to verifying the authorization information value and disclosing whether the authorization information is set in the info response to the sponsoring or non-sponsoring registrar.  Defining a BCP would help to make things more consistent.  draft-gould-regext-secure-authinfo-transfer does not cover what elements are returned in a full or partial info response.  My thought is that if the valid authorization information is provided by a non-sponsoring registrar that the full info response should be returned.  Something like that could be added to draft-gould-regext-secure-authinfo-transfer if it would help with the transfer.  Your thoughts on this would be helpful.    
    
    -- 
      Patrick Mevzek
      pm@dotandco.com
    
    _______________________________________________
    regext mailing list
    regext@ietf.org
    https://www.ietf.org/mailman/listinfo/regext