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 had another thought on the subject, another model. I am posting it here in case there are future discussions, I do not push for discussing now but I think it needs to be on the table as I believe it to offer an alternative that I do not judge as being better or worse than what is in section 4 of the draft but I think it has basically the same threat model attached to it and at least the nice property of not requiring the registry to be mandated to handle authInfo tokens in specific way, which is for me outside EPP merit (but it keeps some other defects, like a state per domain at registry side) So here is the background, and the assumptions: - the authInfo is only used to authorize transfers, outside that it is useless - the registrant just passes this code from current to prospective registrar when it is starting a transfer process - when the registrant goes to old registrar to get the authInfo, I think it already knows who the new registrar would be If any of the above is not true, then the below will not work. But if the assumptions hold, here is the alternative way: - domains do not need authInfo codes anymore, at all - when a registrant want to stage a new transfer, it goes to the current registrar and in some appropriate section makes the registrar sending a command to "open" a transfer period, after having selected the future registrar concerned; in reply to this command the registry gives a one time token (even time limited) permitted to do the transfer between the specific 2 registrars - the registrant goes to the new registrar and starts the transfer with the specific token given; in fact in that case the transfer could even be immediate, as the previous registrar in fact already gave its consent by "opening" the transfer window. Registrars almost do not have to store it, and even if they do the token is tied to a specific operation (a transfer), in a specific time frame, and ideally between 2 registrars. A far lighter authorization token than the full authInfo attached to a domain. The EPP allocationToken extension could even be probably used for that. I think it could easily fit in the current model by having transfer op=prepare for example as a new case (yes I know that the XML schemas does not allow extending those values) In a way it is similar to some registries implementing a "push" transfer that is indeed reversed from the current EPP flows as operations are under control of the current registrar. Ok, the big problem would be for all registrars to maintain the list of current registrars for the registrant to choose from. Complicated but not impossible. And not mandatory strictly for the above to work in fact. Also, if one wants to bring other ideas on the table I think that some thinking could be done around how CA handle authorization to deliver certificates: by a specific change in the DNS, or the website (or in some previous iteration of the guidelines, and somethings that comes fully back in the domain name business, by a specific change in the content of Whois output, like in addresses, or nowadays similarly in RDAP). Again, with a similar threat model, a specific change in the DNS output or the RDDS output (I would be less inclined to include web changes here first because not all domains may have a working website and second because this goes quite outside the domain name industry purely and adds more threat surface) could be enough to authorize the transfer. This could go like this: - registrant goes to new registrar, and requests transfer; no authorization token is required - registry replies saying to registrar something that needs to be given back to registrant: "to authorize this transfer, add a resource record TXT in your zone file at name XXXXXX with content YYYYY; or add a street element in whois being XXXX" - if the registrant, through supposedly the current registrar for second option, or even himself directly for first option if he manages its nameservers, does the requested change, then the transfer is automatically acknowledged by the registry. The registry would have to poll from time to time to check if the changes requested appear, and limit things to a specific time window. The biggest drawback is that in this scheme the current registrar may not have any explicit guaranteed way to oppose any outgoing transfer (because some changes outside of it could be enough to authorize the transfer)... except that is what the status clientTransferProhibited was made for. -- Patrick Mevzek p...@dotandco.com _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
