Change:
10.3. <del> The account recovery processes described in account-recovery allow authorization to be transferred from one account key to another, in case the former account key pair's private key is lost.  ACME needs to prevent these processes from being exploited by an attacker to hijack the authorizations attached to one key and assign them to a key of the attacker's choosing. Recovery takes place in two steps: 1.  Provisioning recovery information (contact or recovery key) 2.  Using recovery information to recover an account The provisioning process needs to ensure that only the account key holder ends up with information that is useful for recovery.  The recovery process needs to assure that only the (now former) account key holder can successfully execute recovery, i.e., that this entity is the only one that can choose the new account key that receives the capabilities held by the account being recovered. Account recovery uses both the ACME channel and the contact channel. The provisioning process is only visible to an ACME MitM, and even then, the MitM can only observe the contact information provided.  If the ACME attacker does not also have access to the contact channel, there is no risk. The security of the recovery process is entirely dependent on the security of the contact channel.  The details of this will depend on the specific out-of-band technique used by the server.  For example: If the server requires a user to click a link in a message sent to a contact address, then the contact channel will need to ensure that the message is only available to the legitimate owner of the contact address.  Otherwise, a passive attacker could see the link and click it first, or an active attacker could redirect the message. If the server requires a user to respond to a message sent to a contact address containing a secret value, then the contact channel will need to ensure that an attacker cannot observe the secret value and spoof a message from the contact address. In practice, many contact channels that can be used to reach many clients do not provide strong assurances of the types noted above. In designing and deploying recovery schemes, ACME servers operators will need to find an appropriate balance between using contact channels that can reach many clients and using contact-based recovery schemes that achieve an appropriate level of risk using those contact channels. 10.4. </del> As a protocol run over HTTPS, standard considerations for TCP-based and HTTP-based DoS mitigation also apply to ACME.

Discussion:
We already removed token-based account recovery; this PR removes contact-based recovery. It was already almost entirely unspecified, due to it being a process that primarily takes place outside of ACME. Removing account recovery from ACME simplifies both the protocol and the security considerations. As an alternative, this PR adds an field to the dictionary in the directory, which the CA can use to expose account management functions such as recovery. But you can also imagine using this for more sophisticated account management functions, like associating an ACME account with some other account in a different system.
(Also threw in some editorial corrections, sorry)
The editorial corrections are good and IMO should be taken in any circumstances. I agree this change does what it says it does, so r+. One concern, which I will cross-post to the list, is that the placement of this URL in the directory means that it is not customizable; It could be a useful thing to, after a signed request, give back a URI that contains a one-time value that would help tie a browser session to a given account key. I don't see a good endpoint for such a thing at present, so the hour is probably too late for such a change.
NAME I agree that could be useful, but I can think of other, simpler ways to provide it (e.g., a link relation from a registration URI). If you think it's important, please file a follow-on issue.
NAME See my feedback on the ACME list. I disagree that this should be merged now. Could you please submit a revert and seek further discussion?
Sorry, I misunderstood. Will revert.