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
position.
Thanks,
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:
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...)
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
p...@dotandco.com
_______________________________________________
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
