Re: [regext] FW: New Version Notification for draft-gould-regext-secure-authinfo-transfer-00.txt

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 <pm@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
>  pm@dotandco.com
> 
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext