Draft: draft-ietf-acme-acme

Commentary: As discussed at the F2F meeting at IETF94 , MAC - based account recovery is not adding a lot of value , and it adds significant complexity to the spec . ( And nobody has implemented it . ) This PR removes MAC - based recovery and the crypto that it depends on . 
 Seeing no complaints on the mailing list , merging .
Paragraph (version A):
If the client wishes to establish a secret key with the server that
it can use to recover this account later (a "recovery key"), then it
must perform a simple key agreement protocol as part of the new-
registration transaction.  The client and server perform an ECDH
exchange through the new-registration transaction (using the
technique in key-agreement), and the result is the recovery key.
Paragraph (version A):
To request a recovery key, the client includes a "recoveryKey" field
in its new-registration request.  The value of this field is a JSON
object.
Paragraph (version A):
The length of the derived secret, in octets.
Paragraph (version A):
In the client's request, this object contains a JWK for a random ECDH
public key generated by the client and the client-selected length
value.  Clients need to choose length values that balance security
and usability.  On the one hand, a longer secret makes it more
difficult for an attacker to recover the secret when it is used for
recovery (see mac-based-recovery).  On the other hand, clients may
wish to make the recovery key short enough for a user to easily write
it down.
Paragraph (version A):
The server MUST validate that the elliptic curve ("crv") and length
value chosen by the client are acceptable, and that it is otherwise
willing to create a recovery key.  If not, then it MUST reject the
new-registration request.
Paragraph (version A):
If the server agrees to create a recovery key, then it generates its
own random ECDH key pair and combines it with the client's public key
as described in key-agreement above, using the label "recovery".  The
derived secret value is the recovery key.  The server then returns to
the client the ECDH key that it generated.  The server MUST generate
a fresh key pair for every transaction.
Paragraph (version A):
On receiving the server's response, the client can compute the
recovery key by combining the server's public key together with the
private key corresponding to the public key that it sent to the
server.
Paragraph (version A):
Clients may refresh the recovery key associated with a registration
by sending a POST request with a new recoveryKey object.  If the
server agrees to refresh the recovery key, then it responds in the
same way as to a new registration request that asks for a recovery
key.
Paragraph (version A):
With MAC-based recovery, the client proves to the server that it
holds a secret value established in the initial registration
transaction.  The client requests MAC-based recovery by sending a MAC
over the new account key, using the recovery key from the initial
registration.
Paragraph (version A):
A JSON-formatted JWS object using an HMAC algorithm, whose payload
is the JWK representation of the public key of the new account key
pair.
Paragraph (version A):
If those conditions are met, and the recovery request is otherwise
acceptable to the server, then the recovery process has succeeded.
The server creates a new registration resource based on the base
registration and the new account key, and returns it on a 201
(Created) response, together with a Location header indicating a URI
for the new registration.  If the recovery request is unsuccessful,
the server returns an error response, such as 403 (Forbidden).
Paragraph (version A):
In the contact-based recovery process, the client requests that the
server send a message to one of the contact URIs registered for the
account.  That message indicates some action that the server requires
the client's user to perform, e.g., clicking a link in an email.  If
the user successfully completes the server's required actions, then
the server will bind the account to the new account key.
Paragraph (version A):
To initiate contact-based recovery, the client sends a POST request
to the server's recover-registration URI, with a body specifying
which registration is to be recovered.  The body of the request MUST
be signed by the client's new account key pair.
Paragraph (version A):
If the server agrees to attempt contact-based recovery, then it
creates a new registration resource containing a stub registration
object.  The stub registration has the client's new account key and
contacts, but no authorizations or certificates associated.  The
server returns the stub contact in a 201 (Created) response, along
with a Location header field indicating the URI for the new
registration resource (which will be the registration URI if the
recovery succeeds).
Paragraph (version B):
The client requests recovery by asking that the server send a message
to one of the contact URIs registered for the account.  That message
indicates some action that the server requires the client's user to
perform, e.g., clicking a link in an email.  If the user successfully
completes the server's required actions, then the server will bind
the account to the new account key.
Paragraph (version B):
To initiate recovery, the client sends a POST request to the server's
recover-registration URI, with a body specifying which registration
is to be recovered.  The body of the request MUST be signed by the
client's new account key pair.
Paragraph (version B):
If the server agrees to attempt recovery, then it creates a new
registration resource containing a stub registration object.  The
stub registration has the client's new account key and contacts, but
no authorizations or certificates associated.  The server returns the
stub contact in a 201 (Created) response, along with a Location
header field indicating the URI for the new registration resource
(which will be the registration URI if the recovery succeeds).
Paragraph (version A):
MAC-based recovery can be performed if the attacker knows the account
key and registration URI for the account being recovered.  Both of
these are difficult to obtain for a network attacker, because ACME
uses HTTPS, though if the recovery key and registration URI are
sufficiently predictable, the attacker might be able to guess them.
An ACME MitM can see the registration URI, but still has to guess the
recovery key, since neither the ECDH in the provisioning phase nor
HMAC in the recovery phase will reveal it to him.
Paragraph (version A):
ACME clients can thus mitigate problems with MAC-based recovery by
using long recovery keys.  ACME servers should enforce a minimum
recovery key length, and impose rate limits on recovery to limit an
attacker's ability to test different guesses about the recovery key.
Paragraph (version A):
Contact-based 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.
Paragraph (version B):
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.
Paragraph (version A):
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 contact-based 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.
Paragraph (version B):
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.