On Tue, Jun 25, 2019, at 07:29, Gould, James wrote:
> The Extensible Provisioning Protocol (EPP) Secure Authorization
> Information for Transfer (draft-gould-regext-secure-authinfo-transfer)
> was posted to define a BCP for securing the authorization information
> using the existing EPP RFCs. The overall goal is to have strong,
> random authorization information values, that are short-lived, and that
> are either not stored or stored as cryptographic hash values. Review
> and feedback is appreciated.
I have read your draft and while I can obviously share your operational
experiences and goals to address many shortcomings of current situation
I really believe that such document as written is not a good fit for an RFC,
nor even for the IETF place in general.
Why? Because it only discuss policies, and not protocol matters.
The fact that it does not define any new EPP commands/objects nor EPP XML
namespace
seems to hint clearly that this is not an EPP extension, that it has nothing
to do with the protocol.
Things like that:
> The operational practice will not require the client
> to store the authorization information and will require the
> server to store the authorization information using a
> cryptographic hash.
How the password is stored and handled at the registry is completely
out of EPP scope. It could as well be symmetrically encrypted, and I fail
to see even how this can be enforceable (how will you verify remotely
how the registry stores the password?), as it is not protocol related.
Or:
> and the sponsoring registrar MUST inform the
> registrant of the TTL when the authorization information is provided
> to the registrant.
Registrars exist that do not let registrant choose passwords at creation
(which also hopefully deter bad passwords) and just give it when requested,
for an outgoing transfer (since it is basically useless for anything else).
So the TTL information will have no meaning to registrants.
Also all your process regarding TTLs force registrars to maintain state
(when they set the password) and a machinery to change it after expiration.
This does not provide them any gain, so there is 0 incentive for them to do
that,
and could be only controlled by the registry.
It also absolutely does not take into account all cases that exist today,
and I see absolutely no reason why the IETF would suddenly be the judge of some
registries policies.
One example: some registries do not let registrars choose/set authInfo.
When a transfer has to be done, the current registrar needs to use a specific
EPP command
to request the registry to generate a new authInfo (which can be obtained
through
a followup domain:info), which the registrant will then use at the new
registrar.
This authInfo has even some time to live.
Another example: after a successful transfer, the registry automatically changes
the authInfo.
I am not claiming this is better. Or worse. I am just saying that there are
various policies, and I see no reason for the IETF to order them from bad to
good.
On the opposite side I would be more happy to see attempts to extend the
authInfo.
It has clearly been designed from the beginning at being extensible:
<complexType name="authInfoType">
<choice>
<element name="pw" type="eppcom:pwAuthInfoType"/>
<element name="ext" type="eppcom:extAuthInfoType"/>
</choice>
</complexType>
and
<complexType name="extAuthInfoType">
<sequence>
<any namespace="##other"/>
</sequence>
</complexType>
So in my views the current password based model per domain has died,
and other solutions have to be searched for. Maybe there is space to pursue
in solutions around OTP frameworks.
Any work in this area needs for me to take also into account at least the
related issues:
- registry lock services
- the whole transfer process (since authInfo serves only there), taking into
account
that there may be rules applied to all gTLDs by virtue of their common
contracts,
but then there are all the other registries.
--
Patrick Mevzek
p...@dotandco.com
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
