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

["Gould, James" <[e-mail]>]

Patrick,

Thank you for reading the draft and providing feedback.  I provide answers to your question embedded below.
  
—
 
JG



James Gould
Distinguished Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 

On 7/2/19, 1:56 AM, "regext on behalf of Patrick Mevzek" <[e-mail] on behalf of [e-mail]> 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.

JG - The draft is a Best Current Practice (BCP) per RFC 2026, and not a standards track draft.  The draft describes how to leverage the existing EPP RFCs for addressing the security of the authorization information value for transfers.  EPP can have protocol extensions defined as informational and standards track drafts, as well as operational practices defined as BCP drafts.  There are many examples of IETF BCPs.  This topic is very applicable to the IETF and the REGEXT working group in particular.  
            
    
    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.
    
JG - Why would the storage and handling of the authorization information be out of EPP scope?  Do you agree that a cryptographic hash is more secure than using an encrypted value?  Use of a cryptographic hash is certainly a best practice when it comes to passwords, so why would it not also be for EPP authorization information values?    I don't believe that an IETF draft requires a form of enforcement.  This is certainly an EPP protocol practice, since it addresses the security of a transfer.  

    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.

JG - The TTL does have meaning to the registrant, since they must use the provided authorization information prior to the expiration of the TTL.  The registrant would need to know how long they have to submit the authorization information to the gaining registrar.  It is the losing registrar's choice what TTL to set, so it is the losing registrar's responsibility to inform the registrant of it.  
    
    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.

JG - The gain is reducing the likelihood of the hijacking of domain names.  The draft defines a practice where the registrars can control the TTL, which can be based on registrar-specified factors.    
    
    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.

JG - It's not meant to take into account all cases that exist today, but is meant to define a practice that can secure the authorization information for transfers using existing EPP RFCs.  I would be interested in learning more about the mechanism used to trigger the server into generating a new authorization information value and how the TTL is handled.  I believe the registrar and not the registry should be the one to generate the authorization information values.  

    
    Another example: after a successful transfer, the registry automatically changes
    the authInfo.

JG - I view having long-lived authorization information values as being less secure to clearing the authorization information value upon a successful transfer.  The authorization information value should only be set during the transfer process, which minimizes its risk to compromise. 
    
    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.

JG - You may want to take a stab at defining an alternative mechanism.  I believe that EPP does not need to be extended to make the authorization information secure for transfers.  
    
    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.

JG - I view draft-gould-regext-secure-authinfo-transfer as a starting point to discuss the operation practice that registrars and registries (any registry) can take to secure the transfer using the existing EPP authorization information.  Any ideas that you have to improve it would be greatly appreciated.
    
    
    -- 
      Patrick Mevzek
      [e-mail]
    
    _______________________________________________
    regext mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/regext