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

"James Galvin" <> Fri, 07 February 2020 14:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 255E91207FC for <>; Fri, 7 Feb 2020 06:42:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gxuuti0W4dWY for <>; Fri, 7 Feb 2020 06:42:01 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ABFE5120236 for <>; Fri, 7 Feb 2020 06:42:01 -0800 (PST)
Received: by with SMTP id a23so2418506qka.1 for <>; Fri, 07 Feb 2020 06:42:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version; bh=MnA94sITbUc20nRfYUt4somQB82Yv6s5cpkQ7Pa6VDU=; b=vHYcv4IlkfFR6z1WI1d+mPoki9X2btJPEXvvPyeaobNFWWertAoGGkI9orqzIqzS/9 zpcX+OkyBX7AC/5WU3i8Hhs66spZIFSx3xbllRmkl6TCqEDjZMg9lfdv3ksUMU6uoZP1 b9RCmsLz47I/vl6yeD3XZJ9XVQLwd2dHtqy1b8qWksZ/zY+3ezA5KWk1xUdGzGH12o0p d7Fwktsx7pvIQRrRvN9LjCJjEtsf6uDK1nB3n/cf3xgIk5bn8LoA7wBY5YcwUEThm7Di dyjHCLzuaNW8aBCLyOc7tbPVrnvUTpt6UTq3+UidYpfXLSXFwElDodWfeTJg/6836bSL mL2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version; bh=MnA94sITbUc20nRfYUt4somQB82Yv6s5cpkQ7Pa6VDU=; b=Oq9jAFNxD4iKBWFC6TGIB13JFgzHxOsgLN7L5kG1tu042w4CPJh8eI4gZ0TuOIt3U0 P+WBygSVk54qorXoR9oAYX1TLFxJwaj1ogVWZSxw1AFse3ECM28EL4wmdCUjWt/8MP96 xpCzaAsO7EOFp8IqQyAWokspbtu3HORuyx1Auh7Q7SBfFWNQaqYkIJO/3M3SWJu7eNXg BBRgxtGWrhEPhxL1OFMpjoW6toCKAHuM30CEU0JeyTb3bNNS24LjP03Lu7Fgs0MybtMY vcJ2sIUxm3KVQmr0UHSyc5f/jeWrtsVBawrr8L/yvpAN0tvwLNewyKSBtElEWoPyejjz CAOQ==
X-Gm-Message-State: APjAAAXAh8XfSfqTpljjnX8KvoX1AwJI5rGyBqEREJUyyDBN4Crv/3bj d34c/kcE4O7VgVwdSEQ2B5qKd1v8Qk0=
X-Google-Smtp-Source: APXvYqwbQwAZd1wK6a+FuNl0dkA6PMgewLQxN0CvHREW9tI0LQ23czWDthAYwr2eYGNNeiqbfiph3w==
X-Received: by 2002:a37:bc6:: with SMTP id 189mr7340691qkl.459.1581086520720; Fri, 07 Feb 2020 06:42:00 -0800 (PST)
Received: from [] ([2601:154:c202:9d20:4195:d901:1c66:caed]) by with ESMTPSA id d18sm1377873qke.75.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Feb 2020 06:41:59 -0800 (PST)
From: "James Galvin" <>
To: "Patrick Mevzek" <>
Date: Fri, 07 Feb 2020 09:42:03 -0500
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: <>
Subject: Re: [regext] CALL FOR ADOPTION: draft-gould-regext-secure-authinfo-transfer
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Feb 2020 14:42:04 -0000

Speaking with Chair hat on:

Your message starts by suggesting that this work does not belong in this 
working group but then moves towards discussing a solution for work that 
belongs in this working group.

As the CALL FOR ADOPTION comes to a close, the chairs are leaning 
towards interpreting your message as agreement there is work that could 
be done.  Note that adopting the document does not guarantee that it 
will be published by this working group; that will be decided as part of 
the discussion and review.

Is this okay with you?  If not, please do take some time to clarify your 


Antoin and Jim

On 28 Jan 2020, at 2:28, Patrick Mevzek 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:
>> 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...)
> 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.
> 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).
> 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.
> 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.)
> -- 
>   Patrick Mevzek
> _______________________________________________
> regext mailing list