Draft: draft-ietf-acme-acme

Commentary: Recent developments[[0 ] ] [ [ 1 ] ] [ [ 2 ] ] have identified real - world server / hosting configurations that violate the assumptions of TLS - SNI-01 and its currently specified replacement , TLS - SNI-02 . In light of these issues and the feasibility of addressing them across the entire Internet it seems prudent that the ACME specification remove the affected challenge type pending the development of a better alternative ( TLS - SNI-03 ? ) . This will allow the draft last - call to proceed while the details of TLS - SNI-03 are worked out . The " Default Virtual Hosts " sub - section of the " Operational Considerations " section is removed since it spoke exclusively to a concern with TLS - SNI-02 validation . When the dust has settled on TLS - SNI-03 we should certainly include a section that describes why TLS - SNI-01/02 were removed that could replace this information . [ 0 ] : [ 1 ] : [ 2 ] : 
 I do n't think we need a place - holder in - doc for this 
 r+ with the one comment addressedShould there be any mention of that makes sure we use in a future RFC in case if gets re- ?
Paragraph (version A):
Different challenges allow the server to obtain proof of different
aspects of control over an identifier.  In some challenges, like
HTTP, TLS SNI, and DNS, the client directly proves its ability to do
certain things related to the identifier.  The choice of which
challenges to offer to a client under which circumstances is a matter
of server policy.
Paragraph (version B):
Different challenges allow the server to obtain proof of different
aspects of control over an identifier.  In some challenges, like HTTP
and DNS, the client directly proves its ability to do certain things
related to the identifier.  The choice of which challenges to offer
to a client under which circumstances is a matter of server policy.
Paragraph (version A):
The TLS with Server Name Indication (TLS SNI) validation method
proves control over a domain name by requiring the client to
configure a TLS server referenced by the DNS A and AAAA resource
records for the domain name to respond to specific connection
attempts utilizing the Server Name Indication extension RFC6066.  The
server verifies the client's challenge by accessing the TLS server
and verifying a particular certificate is presented.
Paragraph (version A):
A random value that uniquely identifies the challenge.  This value
MUST have at least 128 bits of entropy.  It MUST NOT contain any
characters outside the base64url alphabet, including padding
characters ("=").
Paragraph (version A):
A client responds to this challenge by constructing a self-signed
certificate which the client MUST provision at the domain name
concerned in order to pass the challenge.
Paragraph (version A):
The certificate may be constructed arbitrarily, except that each
certificate MUST have exactly two subjectAlternativeNames, SAN A and
SAN B.  Both MUST be dNSNames RFC5280.
Paragraph (version A):
SAN A MUST be constructed as follows: compute the SHA-256 digest
FIPS180-4 of the challenge token and encode it in lowercase
hexadecimal form.  The dNSName is "x.y.token.acme.invalid", where x
is the first half of the hexadecimal representation and y is the
second half.
Paragraph (version A):
SAN B MUST be constructed as follows: compute the SHA-256 digest of
the key authorization and encode it in lowercase hexadecimal form.
The dNSName is "x.y.ka.acme.invalid" where x is the first half of the
hexadecimal representation and y is the second half.
Paragraph (version A):
The client MUST ensure that the certificate is served to TLS
connections specifying a Server Name Indication (SNI) value of SAN A.
Paragraph (version A):
The response to the TLS-SNI challenge simply acknowledges that the
client is ready to fulfill this challenge.
Paragraph (version A):
The key authorization for this challenge.  This value MUST match
the token from the challenge and the client's account key.
Paragraph (version A):
On receiving a response, the server MUST verify that the key
authorization in the response matches the "token" value in the
challenge and the client's account key.  If they do not match, then
the server MUST return an HTTP error in response to the POST request
in which the client sent the challenge.
Paragraph (version A):
Compute SAN A and SAN B in the same way as the client.
Paragraph (version A):
Open a TLS connection to the domain name being validated,
presenting SAN A in the SNI field.  This connection MUST be sent
to TCP port 443 on the TLS server.  In the ClientHello initiating
the TLS handshake, the server MUST include a server_name extension
(i.e., SNI) containing SAN A.  The server SHOULD ensure that it
does not reveal SAN B in any way when making the TLS connection,
such that the presentation of SAN B in the returned certificate
proves association with the client.
Paragraph (version A):
Verify that the certificate contains a subjectAltName extension
containing dNSName entries of SAN A and SAN B and no other
entries.  The comparison MUST be insensitive to case and ordering
of names.
Paragraph (version A):
If all of the above verifications succeed, then the validation is
successful.  Otherwise, the validation fails.
Paragraph (version A):
There are several ways that these assumptions can be violated, both
by misconfiguration and by attacks.  For example, on a web server
that allows non-administrative users to write to .well-known, any
user can claim to own the web server's hostname by responding to an
HTTP challenge, and likewise for TLS configuration and TLS SNI.
Similarly, if a server that can be used for ACME validation is
compromised by a malicious actor, then that malicious actor can use
that access to obtain certificates via ACME.
Paragraph (version B):
There are several ways that these assumptions can be violated, both
by misconfiguration and by attacks.  For example, on a web server
that allows non-administrative users to write to .well-known, any
user can claim to own the web server's hostname by responding to an
HTTP challenge.  Similarly, if a server that can be used for ACME
validation is compromised by a malicious actor, then that malicious
actor can use that access to obtain certificates via ACME.
Paragraph (version A):
It is RECOMMENDED that the server perform DNS queries and make HTTP
and TLS connections from various network perspectives, in order to
make MitM attacks harder.
Paragraph (version B):
It is RECOMMENDED that the server perform DNS queries and make HTTP
connections from various network perspectives, in order to make MitM
attacks harder.
Paragraph (version A):
In many cases, TLS-based services are deployed on hosted platforms
that use the Server Name Indication (SNI) TLS extension to
distinguish between different hosted services or "virtual hosts".
When a client initiates a TLS connection with an SNI value indicating
a provisioned host, the hosting platform routes the connection to
that host.
Paragraph (version A):
When a connection comes in with an unknown SNI value, one might
expect the hosting platform to terminate the TLS connection.
However, some hosting platforms will choose a virtual host to be the
"default", and route connections with unknown SNI values to that
host.
Paragraph (version A):
In such cases, the owner of the default virtual host can complete a
TLS-based challenge (e.g., "tls-sni-02") for any domain with an A
record that points to the hosting platform.  This could result in
mis-issuance in cases where there are multiple hosts with different
owners resident on the hosting platform.
Paragraph (version A):
A CA that accepts TLS-based proof of domain control should attempt to
check whether a domain is hosted on a domain with a default virtual
host before allowing an authorization request for this host to use a
TLS-based challenge.  Typically, systems with default virtual hosts
do not allow the holder of the default virtual host to control what
certificates are presented on a request-by-request basis.  Rather,
the default virtual host can configure which certificate is presented
in TLS on a fairly static basis, so that the certificate presented
should be stable over small intervals.
Paragraph (version A):
A CA can detect such a bounded default vhost by initiating TLS
connections to the host with random SNI values within the namespace
used for the TLS-based challenge (the "acme.invalid" namespace for
"tls-sni-02").  If it receives the same certificate on two different
connections, then it is very likely that the server is in a default
virtual host configuration.  Conversely, if the TLS server returns an
unrecognized_name alert, then this is an indication that the server
is not in a default virtual host configuration.
Paragraph (version A):
The http-01, tls-sni-02 and dns-01 validation methods mandate the
usage of a random token value to uniquely identify the challenge.
The value of the token is required to contain at least 128 bits of
entropy for the following security properties.  First, the ACME
client should not be able to influence the ACME server's choice of
token as this may allow an attacker to reuse a domain owner's
previous challenge responses for a new validation request.  Secondly,
the entropy requirement prevents ACME clients from implementing a
"naive" validation server that automatically replies to challenges
without participating in the creation of the initial authorization
request.
Paragraph (version B):
The http-01, and dns-01 validation methods mandate the usage of a
random token value to uniquely identify the challenge.  The value of
the token is required to contain at least 128 bits of entropy for the
following security properties.  First, the ACME client should not be
able to influence the ACME server's choice of token as this may allow
an attacker to reuse a domain owner's previous challenge responses
for a new validation request.  Secondly, the entropy requirement
prevents ACME clients from implementing a "naive" validation server
that automatically replies to challenges without participating in the
creation of the initial authorization request.