It's worth noting that there are "operational practices" RFCs (6781 being the obvious example) that do not describe a protocol, and are published as Informational documents. This document seems more like those than a protocol specification.
G. > On 2 Jul 2019, at 06:56, Patrick Mevzek <p...@dotandco.com> wrote: > > > > 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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
